headers
Heiher | 1 Dec 2011 02:23
Gravatar

Re: About fpr usage in mips64

Loongson-3a specific instructions are used in this program, so I use
"-march=loongson3a -mabi=32" to compile it. The configure script will use
-march to probe whether these instructions are supported, and I don't want
to break this behavior. P.S: Loongson-3a is mips64 compatible, it has the
same behavior to use FPRs as mips64.

On Thu, Dec 1, 2011 at 12:57 AM, Ian Lance Taylor <iant <at> google.com> wrote:
> Heiher <admin <at> heiher.info> writes:
>
>> I want to use ICT Loongson 3A extension SIMD instructions in o32 ABI
>> program. The march loongson3a is based on mips64. -mfp32 don't work...
>
> I guess I don't know what it means to use -mips64 with -mabi=32.  I'm
> not surprised that it doesn't work.  I don't even think this is is a
> bug.  You explained why you want to use -mips64, but why do you want to
> use -mabi=32?  Why not just recompile the program?
>
> If you can't recompile the program, then as far as I can see you are
> going to have to write some sort of stubs to call between your o32 code
> and your mips64 code.
>
> Ian
>
>> On Wed, Nov 30, 2011 at 2:42 PM, Ian Lance Taylor <iant <at> google.com> wrote:
>>> Heiher <admin <at> heiher.info> writes:
>>>
>>>> The o32 abi programs could only use even-numbered floating-point
>>>> registers by appointment. The GCC generate assembly source  code using
>>>> odd-numbered floating-point register when I -march=mips64 and
>>>> -mabi=32. Every double floating-point instructions will use 32-bit
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ian Lance Taylor | 1 Dec 2011 06:32
Picon
Favicon
Gravatar

Re: About fpr usage in mips64

Heiher <admin <at> heiher.info> writes:

> Loongson-3a specific instructions are used in this program, so I use
> "-march=loongson3a -mabi=32" to compile it. The configure script will use
> -march to probe whether these instructions are supported, and I don't want
> to break this behavior. P.S: Loongson-3a is mips64 compatible, it has the
> same behavior to use FPRs as mips64.

If the instructions are used in asm statements, rather than generated by
the compiler, you can probably use ".set" in the asm statements to tell
the assembler to accept the instructions.

Ian

> On Thu, Dec 1, 2011 at 12:57 AM, Ian Lance Taylor <iant <at> google.com> wrote:
>> Heiher <admin <at> heiher.info> writes:
>>
>>> I want to use ICT Loongson 3A extension SIMD instructions in o32 ABI
>>> program. The march loongson3a is based on mips64. -mfp32 don't work...
>>
>> I guess I don't know what it means to use -mips64 with -mabi=32.  I'm
>> not surprised that it doesn't work.  I don't even think this is is a
>> bug.  You explained why you want to use -mips64, but why do you want to
>> use -mabi=32?  Why not just recompile the program?
>>
>> If you can't recompile the program, then as far as I can see you are
>> going to have to write some sort of stubs to call between your o32 code
>> and your mips64 code.
>>
>> Ian
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ayonam Ray | 1 Dec 2011 07:17
Picon

Scratch register allocation in RTLs post reload

My architecture doesn't have native support for half-word
loads/stores.   We need to do a full word load and then use some
scratch registers to pick the relevant half word using several
operations by using a bunch of scratch registers.  These operations
are done via a bunch of define_splits that use these scratches.  I
have defined the define_expand and define_insn as below:

(define_expand "movhi"
 [(parallel [(set (match_operand:HI 0 "nonimmediate_operand" "")
                  (match_operand:HI 1 "general_operand" ""))
             (set (match_scratch:SI 2 "") (const_int 0))
             (set (match_scratch:SI 3 "") (const_int 0))
             (set (match_scratch:HI 4 "") (const_int 0))
             (set (match_scratch:BI 5 "") (const_int 0))])]
 ""
 {
  ...
 })

(define_insn "*movhi"
 [(parallel [(set (match_operand:HI 0 "nonimmediate_operand" "=r,r,r,r,m")
                  (match_operand:HI 1 "general_operand"       "r,J,I,m,r"))
             (set (match_scratch:SI 2 "=r,X,X,r,r") (const_int 0))
             (set (match_scratch:SI 3 "=r,X,X,r,r") (const_int 0))
             (set (match_scratch:HI 4 "=r,X,X,r,r") (const_int 0))
             (set (match_scratch:BI 5 "=ceq,X,X,ceq,ceq") (const_int 0))])]
 ""
 " <at> 
...
)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ian Lance Taylor | 1 Dec 2011 07:42
Picon
Favicon
Gravatar

Re: Scratch register allocation in RTLs post reload

Ayonam Ray <ayonam <at> gmail.com> writes:

> The problem that I face with this is that post reload, in the CSE and
> combine passes, it looks like generating this instruction but is
> unable to allocate the scratch registers (as expected).  Hence it
> fails while trying to match the constraints in post CSE (in function
> reload_cse_simplify_operands).  The scratches do not match the 'r'
> constraint and hence fail.  How do I prevent it from generating this
> instruction post-reload?  Or is there some other solution to it?

Look at the target hook TARGET_SECONDARY_RELOAD.

Ian
Permalink | Reply | 1 comment |
headers
Georg-Johann Lay | 1 Dec 2011 10:40
Picon
Favicon

ld: bad -plugin option

Hi, I am running into this error from ld since I removed --disable-lto from the
configure.  I used --disable-lto some time because of problems with LTO.

Anyways, I'd like to build with LTO again and get this really not-very-specific
error

/home/georg/install/gcc-4.7/lib/gcc/avr/4.7.0/../../../../avr/bin/ld: bad
-plugin option
collect2: error: ld returned 1 exit status

Notice that binutils are configured --enable-plugins and not --enable-plugin

Thanks to Ian for spotting that typo.

== C Source (main.c) ==

int main()
{
    return 0;
}

 == Command line ==

> /home/georg/install/gcc-4.7/bin/avr-gcc main.c -mmcu=atmega128 -flto -v
-save-temps -Wl,-v

== Message ==

/home/georg/install/gcc-4.7/lib/gcc/avr/4.7.0/../../../../avr/bin/ld: bad
-plugin option
(Continue reading)

Permalink | Reply | 6 comments |
headers
Georg-Johann Lay | 1 Dec 2011 13:18
Picon
Favicon

Re: ld: bad -plugin option

Georg-Johann Lay wrote:
> Hi, I am running into this error from ld since I removed --disable-lto from the
> configure.  I used --disable-lto some time because of problems with LTO.
> 
> Anyways, I'd like to build with LTO again and get this really not-very-specific
> error
> 
> /home/georg/install/gcc-4.7/lib/gcc/avr/4.7.0/../../../../avr/bin/ld: bad
> -plugin option
> collect2: error: ld returned 1 exit status

Calling ld directly yields:

$ /home/georg/install/gcc-4.7/lib/gcc/avr/4.7.0/../../../../avr/bin/ld --help |
grep -i plug
  -plugin PLUGIN              Load named plugin
  -plugin-opt ARG             Send arg to last-loaded plugin
/home/georg/install/gcc-4.7/lib/gcc/avr/4.7.0/../../../../avr/bin/ld: supported
targets: elf32-avr elf32-little elf32-big plugin srec symbolsrec verilog tekhex
binary ihex

So there is nothing wrong with the install.

$ ll /home/georg/install/gcc-4.7/libexec/gcc/avr/4.7.0/liblto_plugin.so
/home/georg/install/gcc-4.7/libexec/gcc/avr/4.7.0/liblto_plugin.so ->
liblto_plugin.so.0.0.0

$ ls -al /home/georg/install/gcc-4.7/libexec/gcc/avr/4.7.0/liblto*
 /home/georg/install/gcc-4.7/libexec/gcc/avr/4.7.0/liblto_plugin.la
 /home/georg/install/gcc-4.7/libexec/gcc/avr/4.7.0/liblto_plugin.so ->
(Continue reading)

Permalink | Reply | 5 comments |
headers
Ayonam Ray | 1 Dec 2011 13:22
Picon

Re: Scratch register allocation in RTLs post reload

Thanks a ton Ian for pointing to the right place.  I got it.

Regards
Ayonam  01/12/11  1750 Hrs.

On 1 December 2011 12:12, Ian Lance Taylor <iant <at> google.com> wrote:
> Ayonam Ray <ayonam <at> gmail.com> writes:
>
>> The problem that I face with this is that post reload, in the CSE and
>> combine passes, it looks like generating this instruction but is
>> unable to allocate the scratch registers (as expected).  Hence it
>> fails while trying to match the constraints in post CSE (in function
>> reload_cse_simplify_operands).  The scratches do not match the 'r'
>> constraint and hence fail.  How do I prevent it from generating this
>> instruction post-reload?  Or is there some other solution to it?
>
> Look at the target hook TARGET_SECONDARY_RELOAD.
>
> Ian
>
Permalink | Reply | 0 comments |
headers
Aurelien Buhrig | 1 Dec 2011 14:09
Picon

Re: best ABI strategy ?

2011/11/30 Ian Lance Taylor <iant <at> google.com>:
> Aurelien Buhrig <aurelien.buhrig.gcc <at> gmail.com> writes:
>
>> I'm trying to optimize our target ABI, and I'm wondering what is the
>> best strategy to define it.
>> Is there a paper, or any hint, dealing with this topic ?
>> For instance,
>> - which ratio between call-used-reg vs "static regs"
>> - which ratio between arg regs vs call-used-reg
>> - what should be return regs
>> - ...
>> I guess this problem is very target dependent, but there are maybe
>> general ideas about this.
>
> I don't know of any papers on this topic.
>
> There are several things that feed into this, including:
>
> * The relative cost of saving registers on the stack.
>
> * How orthogonal your register set is--e.g., are there any registers
>  with special purposes in the ISA?  Are there different register
>  classes that hold different types of values?  Are there any
>  restrictions on which registers can be used in a memory address?
>
> * How many registers you have overall.
>
> * What kind of code you are most interested in optimizing.  E.g., image
>  processing code tends to lead to functions with lots of loops with
>  lots of loop local variables that benefit from being in registers.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Georg-Johann Lay | 1 Dec 2011 17:20
Picon
Favicon

Re: collect2 picks wrong target-ld (was: ld: bad -plugin option)

Georg-Johann Lay wrote:
> Georg-Johann Lay wrote:
>> Hi, I am running into this error from ld since I removed --disable-lto from the
>> configure.  I used --disable-lto some time because of problems with LTO.
>>
>> Anyways, I'd like to build with LTO again and get this really not-very-specific
>> error
>>
>> /home/georg/install/gcc-4.7/lib/gcc/avr/4.7.0/../../../../avr/bin/ld: bad
>> -plugin option
>> collect2: error: ld returned 1 exit status
> 
> Calling ld directly yields:
> 
> $ /home/georg/install/gcc-4.7/lib/gcc/avr/4.7.0/../../../../avr/bin/ld --help |
> grep -i plug
>   -plugin PLUGIN              Load named plugin
>   -plugin-opt ARG             Send arg to last-loaded plugin
> /home/georg/install/gcc-4.7/lib/gcc/avr/4.7.0/../../../../avr/bin/ld: supported
> targets: elf32-avr elf32-little elf32-big plugin srec symbolsrec verilog tekhex
> binary ihex
> 
> So there is nothing wrong with the install.
> 
> $ ll /home/georg/install/gcc-4.7/libexec/gcc/avr/4.7.0/liblto_plugin.so
> /home/georg/install/gcc-4.7/libexec/gcc/avr/4.7.0/liblto_plugin.so ->
> liblto_plugin.so.0.0.0
> 
> 
> $ ls -al /home/georg/install/gcc-4.7/libexec/gcc/avr/4.7.0/liblto*
(Continue reading)

Permalink | Reply | 4 comments |
headers
Alireza Haghdoost | 1 Dec 2011 19:12
Picon

reduce compilation cost for changing a bit in headers

Hi

When ever I change a .h file, I have to make clean and recompile whole
project. However only one object file need recompilation. Is there any
way to make this process more efficient ? I mean is there any way that
it find a change in a header file and only recompile it's depended
object files ?

Alireza
Permalink | Reply | 4 comments |

Gmane