Re: Where is DESTDIR got defined in gcc makefile?

[Amker . Cheng]

I used buildroot tool to build GCC and did not get the make command line,
so didn't find it.
Thanks.

On Sun, Dec 7, 2008 at 11:24 PM, Brian Dessent <[EMAIL PROTECTED]> wrote:
> "Amker.Cheng" wrote:
>
>> Here the destination directory is $(DESTDIR)$(libexecsubdir)/, but
>> where is DESTDIR defined?
>> I did not find any definition of this variable in both toplevel and
>> gcc's makefile.
>
> It's intentionally not defined anywhere as it's expected to remain unset
> unless the user overrides it.  See
> .
>
> Brian
>

Re: questions about "find_if_case"

[Steven Bosscher]

On Mon, Dec 8, 2008 at 8:54 AM, Eric Fisher <[EMAIL PROTECTED]> wrote:
> Hi,
>
>  For if-conversion pass (pass_if_after_combine), we can see there're
> some IF-THEN-ELSE cases which we try to transform. Let's say
> find_if_case_1, for an example.
>
> (1)
>if (test) goto over; // x not live
>x = a;
>goto label;
>over:
>
>   becomes
>
>x = a;
>if (! test) goto label;
>
>   One of my questions is what the benefit this convertion can attain?

It avoids a branch instruction.  For the first case, the path via "x =
a" is "test -> jump -> set -> jump" (where "set" is th "x =
a"-instruction).  This becomes "set -> test -> jump".  So one jump
less.

The assumption is that a branch instruction is much more expensive
than a register set.  Which brings us to...

>   Also, there's a precondition, which the THEN bb must cost cheap
> then BRANCH_COST. I'm not clear about the reason.

... this test to verify the abovementioned assumption.  THEN_BB
contains the "x = a"-instruction. So the precondition verifies that
the branch instruction is expensive enough to avoid compared to
executing "x = a" on a path where x is not live.

So, the decision to perform the transformation or not, is a cost
trade-off between executing an extra branch instruction and creating
partially dead code.

Gr.
Steven

[ARM] Implement __builtin_bswap32() via ARMv6 "rev" instruction

[Alexandre Pereira Nunes]

A patch follows. I didn't take care of the scheduling case the correct
way, tought (aliased to clz class).

Can someone please review (works for me (c)) and merge?

-- Alexandre
--- gcc-4.3.2/gcc/config/arm/arm.md~2008-12-05 18:17:09.0 -0200
+++ gcc-4.3.2/gcc/config/arm/arm.md 2008-12-05 18:17:09.0 -0200
@@ -10808,6 +10808,16 @@
   "TARGET_32BIT && arm_arch5e"
   "pld\\t%a0")
 
+;; V6 instructions.
+(define_insn "bswapsi2"
+  [(set (match_operand:SI 0 "s_register_operand" "=r")
+   (bswap:SI (match_operand:SI 1 "s_register_operand" "r")))]
+  "arm_arch6"
+  "rev%?\\t%0, %1"
+  [(set_attr "predicable" "yes")
+   (set_attr "insn" "clz")])
+
+
 ;; General predication pattern
 
 (define_cond_exec

Re: [ARM] Implement __builtin_bswap32() via ARMv6 "rev" instruction

[Paul Brook]

On Monday 08 December 2008, Alexandre Pereira Nunes wrote:
> A patch follows. I didn't take care of the scheduling case the correct
> way, tought (aliased to clz class).

Please read http://gcc.gnu.org/contribute.html

In particular you need a copyright assignment, ChangeLog entry, and testing.

You should also be able to implement bswap16, and while we're here it probably 
makes sense to implement an optimized bswap sequence for pre-v6 cores.

Once all that is fixed, patches should be sent to [EMAIL PROTECTED], not 
this list.

Paul

Re: Reload generating memory ref in memory ref

[Richard Henderson]

Michael Eager wrote:

Another possibility is illegal rtl sharing.


If you mean that an rtx would be pointed to by two different
insn's, how would that happen?  (Excluding someone mucking
things up deliberately or accidentally.)


Generally this sort of mistake happens in the backend somewhere.
E.g. when it is fooling about with insn splitters (with C as
opposed to machine-generated via patterns).


r~

Re: [ARM] Implement __builtin_bswap32() via ARMv6 "rev" instruction

[Alexandre Pereira Nunes]

> 2008/12/8 Paul Brook <[EMAIL PROTECTED]>:
> On Monday 08 December 2008, Alexandre Pereira Nunes wrote:
>> A patch follows. I didn't take care of the scheduling case the correct
>> way, tought (aliased to clz class).
>
> Please read http://gcc.gnu.org/contribute.html
>
> In particular you need a copyright assignment, ChangeLog entry, and testing.
>

 I can provide these, tough as for the copyright assignment, the
 document mentions I can declare the changes in public domain, and
 since I already published something (which may or may not be used by
 someone in the future), I hereby do so.

> You should also be able to implement bswap16, and while we're here it probably
> makes sense to implement an optimized bswap sequence for pre-v6 cores.
>
>
 Arm has rev constructs for 16 bit packed integers, however AFAIK gcc
 has no builtin for these yet, and without this, it won't internally
 have any use for this instruction pattern, correct? I only saw
 mentions to bswap32 and bswap64 on the documentation.

 I'll take a look on the optimized bswap32 sequences for previous cores
 and get these expanded when not optimizing for size, IIRC I saw
 similar patterns on some other architecture machine description.


> Once all that is fixed, patches should be sent to [EMAIL PROTECTED], not
> this list.
>

 Roger that; Thanks.

 -- Alexandre

Re: [ARM] Implement __builtin_bswap32() via ARMv6 "rev" instruction

[Andrew Thomas Pinski]

Sent from my iPhone

On Dec 8, 2008, at 9:37 AM, "Alexandre Pereira Nunes" <[EMAIL PROTECTED] 
> wrote:



2008/12/8 Paul Brook <[EMAIL PROTECTED]>:
On Monday 08 December 2008, Alexandre Pereira Nunes wrote:
A patch follows. I didn't take care of the scheduling case the  
correct

way, tought (aliased to clz class).


Please read http://gcc.gnu.org/contribute.html

In particular you need a copyright assignment, ChangeLog entry, and  
testing.




I can provide these, tough as for the copyright assignment, the
document mentions I can declare the changes in public domain, and
since I already published something (which may or may not be used by
someone in the future), I hereby do so.

You should also be able to implement bswap16, and while we're here  
it probably
makes sense to implement an optimized bswap sequence for pre-v6  
cores.




Arm has rev constructs for 16 bit packed integers, however AFAIK gcc
has no builtin for these yet, and without this, it won't internally
have any use for this instruction pattern, correct? I only saw
mentions to bswap32 and bswap64 on the documentation.


That is because bswap16 is the same as a rotate in 16bit mode by 8.

Thanks,
Andrew Pinski




I'll take a look on the optimized bswap32 sequences for previous cores
and get these expanded when not optimizing for size, IIRC I saw
similar patterns on some other architecture machine description.


Once all that is fixed, patches should be sent to [EMAIL PROTECTED] 
, not

this list.



Roger that; Thanks.

-- Alexandre

Re: [ARM] Implement __builtin_bswap32() via ARMv6 "rev" instruction

[Ian Lance Taylor]

"Alexandre Pereira Nunes" <[EMAIL PROTECTED]> writes:

>  I can provide these, tough as for the copyright assignment, the
>  document mentions I can declare the changes in public domain, and
>  since I already published something (which may or may not be used by
>  someone in the future), I hereby do so.

Unfortunately we need more than that: we need a signed piece of paper
disclaiming copyright.  This is not just to be difficult, it's because
of some unfortunate legal issues which have arisen in the past.  If
you want to proceed along these lines, I can send you the appropriate
form.

Ian

Re: [ARM] Implement __builtin_bswap32() via ARMv6 "rev" instruction

[Nils Pipenbrinck]

Ian Lance Taylor wrote:

Unfortunately we need more than that: we need a signed piece of paper
disclaiming copyright.  


This is something I stumbled over some month ago when I studied the 
submission rules:


I am now a lawyer, but as far as I know in my country (germany) it is 
not possible to decline copyright (called Urheberrecht here - it's not 
exactly the same but close). You can give away the usage-rights to your 
code at will and for free (by putting your code into public domain for 
example), but declining "Urheberrecht" is not possible.


How does the FSF deals with this issue?

TLS on darwin

[IainS]

Hi,

following on from http://gcc.gnu.org/ml/gcc/2008-05/msg00202.html

should I expect

"--enable-tls"

to produce a functional result on {intel,powerpc}-*-darwin{8,9}

or should all testcases with thread local requirements be wrapped with

{ dg-require-effective-target tls_runtime }

thanks,
Iain

Re: TLS on darwin

[Andrew Pinski]

On Mon, Dec 8, 2008 at 1:04 PM, IainS <[EMAIL PROTECTED]> wrote:
> following on from http://gcc.gnu.org/ml/gcc/2008-05/msg00202.html

As I mentioned; it is emulated.  So it works, by default, though it is
not native support (that is there is no ABI helper that speeds it up).
 In fact tls_runtime should be true for almost all targets anyways as
the emulation works without threads too.

Thanks,
Andrew Pinski

Re: [ARM] Implement __builtin_bswap32() via ARMv6 "rev" instruction

[Ian Lance Taylor]

Nils Pipenbrinck <[EMAIL PROTECTED]> writes:

> I am now a lawyer, but as far as I know in my country (germany) it is
> not possible to decline copyright (called Urheberrecht here - it's not
> exactly the same but close). You can give away the usage-rights to
> your code at will and for free (by putting your code into public
> domain for example), but declining "Urheberrecht" is not possible.
>
> How does the FSF deals with this issue?

The FSF copyright office has been dealing with these issues for many
years.  I suggest that you ask them.

Ian

Re: Reload generating memory ref in memory ref

[Jeff Law]

Richard Henderson wrote:

Michael Eager wrote:

Another possibility is illegal rtl sharing.


If you mean that an rtx would be pointed to by two different
insn's, how would that happen?  (Excluding someone mucking
things up deliberately or accidentally.)


Generally this sort of mistake happens in the backend somewhere.
E.g. when it is fooling about with insn splitters (with C as
opposed to machine-generated via patterns).

A badly written LEGITIMIZE_RELOAD_ADDRESS can trigger this kind of 
failure as well.


jeff

Re: questions about "find_if_case"

[Eric Fisher]

> It avoids a branch instruction.  For the first case, the path via "x =
> a" is "test -> jump -> set -> jump" (where "set" is th "x =
> a"-instruction).  This becomes "set -> test -> jump".  So one jump
> less.

Thank you very much for the detailed explanation. However, I have a
doubt here. IMO, the path via "x=a" should be "test->set->jump". And
it becomes "set->test->jump". The other path is "test->jump". It
becomes "set->test". So the trade-off is for the latter case. Are
these right?

Best wishes
Eric

redundancy code

[tian xiaonan]

Hello,
   I used the spim5 gcc 4.0.2 to study gcc port. but I found there are lots of 
the 'move' insns redundancy code. For example, the C code like this: 
  i=1; 
  i = i + 5; 
the Spim compiler will generate the code like the following(PS:RX is the 
register) .
 li R0,  #1
 SW R0,  0(MEM)
 LW R0,  0(MEM)
 Addi  R0,  R0,  #5
 SW R0,  0(MEM)

Obviously, there are two insn redundancy. What confused me is how it generated. 
Is problem in the 'define_insn mov' pattern or the define_peephole insn?

spim5 porting backend code 
here:http://www.cse.iitb.ac.in/~uday/gcc-workshop/downloads/IITB-Incremental-Machine-Descriptions/
Thank you.
Tian Xiaonan




  ___ 
  好玩贺卡等你发，邮箱贺卡全新上线！ 
http://card.mail.cn.yahoo.com/

gcc -r

[Ralf Corsepius]

Hi,

2 questions:

1) Is "gcc -r" officially supported by gcc?

It apparently works, but I can't find it documented anywhere in GCC's
documentation.

2) Is "gcc -r" any different from using "gcc -Wl,-r"?

Ralf

Re: Reload generating memory ref in memory ref

[Michael Eager]

Jeff Law wrote:

Richard Henderson wrote:

Michael Eager wrote:

Another possibility is illegal rtl sharing.


If you mean that an rtx would be pointed to by two different
insn's, how would that happen?  (Excluding someone mucking
things up deliberately or accidentally.)


Generally this sort of mistake happens in the backend somewhere.
E.g. when it is fooling about with insn splitters (with C as
opposed to machine-generated via patterns).

A badly written LEGITIMIZE_RELOAD_ADDRESS can trigger this kind of 
failure as well.


I do have a LEGITIMIZE_RELOAD_ADDRESS which is
issuing a reload for registers in addresses.  It seems
to be working is most cases.

How might it be generating a shared rtx?


--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077