Re: define_split

[Joern Rennecke]

Quoting roy rosen :


What is the difference when writing define_insn_and_split?
From what I understood from the docs then if there is such an insn
then the split does not occur so it would simply match it as an insn
without splitting and at the end would print the #?
Can you please elaborate?


The combiner (and other passes) would match it as an insn, but ordinary
splitter passes, e.g. before scheduling, will still split it.

Re: Merging gdc (Gnu D Compiler) into gcc

[Andrew Haley]

On 11/08/2010 11:13 PM, Walter Bright wrote:
> 
> 
> Joseph S. Myers wrote:
>> On Mon, 8 Nov 2010, Walter Bright wrote:
>>
>>  
>>> Who do I need to talk to in order to resolve the various licensing
>>> issues so
>>> this becomes possible?
>>> 
>>
>> The FSF, via the Steering Committee, via this list.  The standard
>> assignment and licensing policies are as described in the Mission
>> Statement .  Any special
>> arrangement like that for the Go front end (where part providing the
>> GCC interface is assigned to the FSF and maintained in the GCC tree
>> and part that could be used with other back ends is maintained
>> externally with third-party copyright) needs specific approval.  (Note
>> that the Go front end does not yet achieve the level of separation
>> achieved by Ada, for example; there are plenty of uses of GCC's tree
>> interfaces in the gofrontend/ directory that mean portability to other
>> back ends is more theory than reality.)
> 
> The D specific part of gdc is already GPL, it's just copyrighted by
> Digital Mars. I understand the copyright must be reassigned to the FSF.
> Is it possible to fork the code, and assign copyright of one fork to the
> FSF and leave the other copyrighted by Digital Mars?

The FSF generally allows a grant-back: that is, you assign your code
to the FSF, which immediately grants you an unlimited licence to do
whatever you want with it.

Andrew.

Re: Merging gdc (Gnu D Compiler) into gcc

[Jakub Jelinek]

On Tue, Nov 09, 2010 at 09:36:08AM +, Andrew Haley wrote:
> > The D specific part of gdc is already GPL, it's just copyrighted by
> > Digital Mars. I understand the copyright must be reassigned to the FSF.
> > Is it possible to fork the code, and assign copyright of one fork to the
> > FSF and leave the other copyrighted by Digital Mars?
> 
> The FSF generally allows a grant-back: that is, you assign your code
> to the FSF, which immediately grants you an unlimited licence to do
> whatever you want with it.

Just note that if you'll want to merge back from the FSF tree back to your
forked tree any changes made there by others, those changes will already be
copyrighted by the FSF and not Digital Mars.

Jakub

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Andi Kleen]

> My speculation is, that the asm is not removed but rather that regs.eax 
> isn't reloaded after the asm because the memory clobber doesn't clobber 
> automatic variables.

Yes that makes sense. I wasn't able to verify it so far though.

Maybe the original poster could try the obvious patch 
instead of the volatile change.


i8k: tell gcc that regs gets clobbered

Signed-off-by: Andi Kleen 

diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
index 3bc0eef..f3bbf73 100644
--- a/drivers/char/i8k.c
+++ b/drivers/char/i8k.c
@@ -142,7 +142,7 @@ static int i8k_smm(struct smm_regs *regs)
"lahf\n\t"
"shrl $8,%%eax\n\t"
"andl $1,%%eax\n"
-   :"=a"(rc)
+   :"=a"(rc), "=m" (*regs)
:"a"(regs)
:"%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");
 #else
@@ -167,7 +167,7 @@ static int i8k_smm(struct smm_regs *regs)
"movl %%edx,0(%%eax)\n\t"
"lahf\n\t"
"shrl $8,%%eax\n\t"
-   "andl $1,%%eax\n":"=a"(rc)
+   "andl $1,%%eax\n":"=a"(rc), "=m" (*regs)
:"a"(regs)
:"%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");
 #endif

-Andi

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Michael Matz]

Hi,

On Mon, 8 Nov 2010, Dave Korn wrote:

> void foo (void)
> {
>   int x, y, z;
>   x = 23;
>   asm ("do something" : "=r" (y) : "r" (x) );
>   z = y + 1;
> }

The case in i8k.c really is different.  It does use the value by 
influencing the return value and the callers use the returned value in 
conditionals and the like.  It really, really _is_ used :-) and if GCC 
removes the asm (which up to now is only speculation) then it's a GCC bug.

The code outlines like so:

int i8k_smm (regs) {
  int rc;
  asm (... : "=r"(rc) ...);
  if (rc != 0 || ...)
return -EINVAL;
  return 0;
}

...
  struct regs regs = {.eax = ...}
  return i8k_smm(regs) ?: regs.eax;
...

My speculation is, that the asm is not removed but rather that regs.eax 
isn't reloaded after the asm because the memory clobber doesn't clobber 
automatic variables.


Ciao,
Michael.

Re: RFC: Add zlib source to src CVS resposity

[Mike Frysinger]

On Tuesday, November 02, 2010 09:22:24 Ian Lance Taylor wrote:
> Nick Clifton  writes:
> >   Right - this decision has been made.  We are not going to include
> > 
> > zlib the in the binutils sources.
> > 
> >   Thanks for suggesting the idea and working on the patch, but in the
> > 
> > end it was just not a path we wanted to go down.
> 
> I think the next decision is whether to require the host system to have
> zlib, much as gcc requires the host system to have gmp, mpfr, and mpc.

since the functionality in binutils is minor and optional, i dont think 
requiring zlib makes sense
-mike


signature.asc
Description: This is a digitally signed message part.

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Andreas Schwab]

Andi Kleen  writes:

> @@ -142,7 +142,7 @@ static int i8k_smm(struct smm_regs *regs)
>   "lahf\n\t"
>   "shrl $8,%%eax\n\t"
>   "andl $1,%%eax\n"
> - :"=a"(rc)
> + :"=a"(rc), "=m" (*regs)

I think this should be "+m".

Andreas.

-- 
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

Re: define_split

[Paolo Bonzini]

On 11/09/2010 10:22 AM, Joern Rennecke wrote:

Quoting roy rosen :


What is the difference when writing define_insn_and_split?
From what I understood from the docs then if there is such an insn
then the split does not occur so it would simply match it as an insn
without splitting and at the end would print the #?
Can you please elaborate?


The combiner (and other passes) would match it as an insn, but ordinary
splitter passes, e.g. before scheduling, will still split it.


As I understand it, this will also give combine the ability to do 
two->two (and two->N) transformations, though indirectly through the 
temporary insn.  Given this, could you explain further the benefits of 
combiner-split define_split vs. define_insn_and_split.


Paolo

Re: Constant propagation and CSE

[Jeff Law]

 On 10/27/10 13:54, Frederic Riss wrote:

On 27 October 2010 21:21, Jeff Law  wrote:

  On 10/27/10 12:15, Frederic Riss wrote:

On 26 October 2010 16:22, Jeff Lawwrote:

The thing is the cprop pass doesn't look at insn costs while doing its
job AFAICS. I'm interested to see how insn splitting can help with
this if you don't care to explain.

Certainly the SSA propagators don't use costing information; CSE on the
other hand does using costing info, but not always in the way you might
think (addresses in memory references for example are often backwards from
what you might think)

Care to extend on that use of the costing info? I followed the code
path in gcse.c and e.g. do_local_cprop doesn't seem to care about
costs. BTW, I'm on the 4.5 branch if that matters.
In both cse.c and gcse.c search for rtx_cost.  The addition of costing 
info in gcse was a fairly recent addition from Maxim.



Register pressure isn't as much of a problem as you might think because
constants are relatively easy to rematerialize when there is excess register
pressure.

That's what I thought, but I have yet to see GCC split the liveness of
the commonized constants. When should that be done?
When a pseudo fails to get a hard register and has an equivalent 
constant or memory location, reload will replace the pseudo with its 
equivalent form, effectively splitting the live range.


jeff

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jim]

On 11/09/2010 02:57 PM, Andreas Schwab wrote:
> Andi Kleen  writes:
> 
>> @@ -142,7 +142,7 @@ static int i8k_smm(struct smm_regs *regs)
>>  "lahf\n\t"
>>  "shrl $8,%%eax\n\t"
>>  "andl $1,%%eax\n"
>> -:"=a"(rc)
>> +:"=a"(rc), "=m" (*regs)
> 
> I think this should be "+m".
> 
> Andreas.
> 

Just tested Andi's patch with Andreas' suggestion to make it +m,
i.e. like attached and can confirm it solves the issue.

Thanks guys,
   Jim Bos


--- i8k.c.ORIG  2010-08-02 17:20:46.0 +0200
+++ i8k.c   2010-11-09 17:31:29.0 +0100
@@ -141,7 +141,7 @@
"lahf\n\t"
"shrl $8,%%eax\n\t"
"andl $1,%%eax\n"
-   :"=a"(rc)
+   :"=a"(rc), "+m" (*regs)
:"a"(regs)
:"%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");
 #else
@@ -166,7 +166,7 @@
"movl %%edx,0(%%eax)\n\t"
"lahf\n\t"
"shrl $8,%%eax\n\t"
-   "andl $1,%%eax\n":"=a"(rc)
+   "andl $1,%%eax\n":"=a"(rc), "+m" (*regs)
:"a"(regs)
:"%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");
 #endif

Re: Merging gdc (Gnu D Compiler) into gcc

[Joe Buck]

On Tue, Nov 09, 2010 at 05:08:44AM -0800, Jakub Jelinek wrote:
> On Tue, Nov 09, 2010 at 09:36:08AM +, Andrew Haley wrote:
> > > The D specific part of gdc is already GPL, it's just copyrighted by
> > > Digital Mars. I understand the copyright must be reassigned to the FSF.
> > > Is it possible to fork the code, and assign copyright of one fork to the
> > > FSF and leave the other copyrighted by Digital Mars?
> > 
> > The FSF generally allows a grant-back: that is, you assign your code
> > to the FSF, which immediately grants you an unlimited licence to do
> > whatever you want with it.
> 
> Just note that if you'll want to merge back from the FSF tree back to your
> forked tree any changes made there by others, those changes will already be
> copyrighted by the FSF and not Digital Mars.

You might be able to get RMS to agree to an alternative arrangement, but
no one but him could approve it.

Re: define_split

[Joern Rennecke]

Quoting Paolo Bonzini :


As I understand it, this will also give combine the ability to do
two->two (and two->N) transformations, though indirectly through the
temporary insn.  Given this, could you explain further the benefits of
combiner-split define_split vs. define_insn_and_split.


A define_insn will be recognized in all contexts. (Unless you use special
 insn conditions, but the only safe place to make an insn cease to be
 valid in a machine-dependent way is TARGET_MACHINE_DEPENDENT_REORG.
 Unless you start writing extra machine-dependent passes and feed them
 to the pass manager.)
Having an insn pattern for an insn that does not actually exist can cause
all kinds of unintended consequences as the optimizers try to generate
and recognize 'optimized' patterns, or when reload does its stuff.

Re: define_split

[Paolo Bonzini]

On 11/09/2010 05:38 PM, Joern Rennecke wrote:

A define_insn will be recognized in all contexts.
Having an insn pattern for an insn that does not actually exist can cause
all kinds of unintended consequences as the optimizers try to generate
and recognize 'optimized' patterns, or when reload does its stuff.


Before reload that is not a problem at all, I think, actually it can be 
an advantage.  At reload or after, the only problem I see is if someone 
is sloppy with constraints.


Paolo

Re: named address spaces: addr_space_convert never called

[Georg Lay]

David Brown schrieb:
> On 08/11/10 16:59, Georg Lay wrote:
>> Richard Guenther schrieb:
>>> On Mon, Nov 8, 2010 at 3:39 PM, Georg Lay  wrote:
 Hi, I just started playing around with named address spaces for avr.
 Besides general space (ram), I introduced a second one, __pgm, which
 shall address program memory where also constants may live. avr is
 havard architecture, and both program memory and ram start at
 address 0.

  From this and the internals on TARGET_ADDR_SPACE_CONVERT I understand
 that pointer casting will not work as expected, because that hook will
 only get called if the respective address spaces are subsets. However,
 neither is space-1 a subset of space-0 nor vice versa (or am I midlead
 by internals?)

 Is there a way to make it work in the case where the address spaces
 are disjoint? Started this morning and everything went smooth until I
 started messing around with pointer casts:

[...]

 So as of internals doc, named address spaces are not intended to
 implement this kind of memory?
>>>
>>> If they are not subsets of each other how'd you convert a pointer
>>> pointing into one to point into the other address-space?  I think
>>> the frontend should diagnose this as invalid.
>>
>> The front end emits warning. However, explicit casts should yield only
>> a warning if explicit requested.
>>
>> With subsets relation returning true the code is like that (I changed
>> the test case to add 5, the there is an additional *addphi).

[...]

>> This is fine.
>>
>> However, I am still confused:
>>
>> "A is a subset of B iff every member of A is alse member of B".
>>
>> But in this case, an element of ram is not an element of flash nor is
>> an element of flash an element of ram. Written down as numbers, these
>> numers are the same, yes, so that information gets encoded in the
>> machine mode to know what addresses are legal and what instruction
>> must be used.
>>
>> Memory is not linearized because that would imply to take the decision
>> at runtime.
>>
> Would be be possible to define a third memory space as "global" memory,
> of which both the ram and the flash are subsets?  It is important to
> keep ram as the default memory space, but perhaps an artificial global
> memory space would let you do  conversions like this safely and without
> warnings.
> 
> Even better would be if the global memory space could have 24-bit (or
> 32-bit if necessary) pointers, so that it would actually encompass all
> memory, with ram pointers at 0x80 to match the addresses used by the
> linker.  It would also make it a lot easier to use the full flash space
> on AVR's with more than 64K flash.

The linker has more information becase it sees relocs/symbols/sections
whatever. The compiler doesn't have this info when it has to access
the memory. In the example given above, there are two cases becase the
application like to destinguith between ram and flash, but I think
that case ir rare. In most cases the application known how to handle a
pointer, and users don't want to see LPM/SBRC/LD sequences or even
more in case of multiple byte access.

> May I say I think it's great that you are looking into this?  Program
> space access on the AVR was the first thing I thought of when I heard of
> the concept of named address spaces in C.

It's great work that this is part of gcc now! Just remember all the
hacks to get near/far support into a C16x target.

Besides access and pointer size, maybe even thinks like

int __far __atomic x;

are sensible for basic types if users aren't confused that in x ^= 1
just the accesses would be atomic, not the operation itself (and don't
mind the overhead if gcc cannot prove that IRQs are disallowed in ISR,
as in presence of call, asm, or memory-access).

However, at present avr backend badly needs avr developers. It's not a
good idea to build such enhancements atop of all the PRs there...

Georg

Re: named address spaces: addr_space_convert never called

[Georg Lay]

> int __far __atomic x;

int volatile __far __atomic x;

makes more sense :-)

Re: define_split

[Joern Rennecke]

Quoting Paolo Bonzini :


On 11/09/2010 05:38 PM, Joern Rennecke wrote:

A define_insn will be recognized in all contexts.
Having an insn pattern for an insn that does not actually exist can cause
all kinds of unintended consequences as the optimizers try to generate
and recognize 'optimized' patterns, or when reload does its stuff.


Before reload that is not a problem at all, I think, actually it can be
an advantage.


No, it is a code quality problem.  And yes, I have seen actual
SH patterns being recognized that were not wanted, and lead to worse
code overall.

Re: named address spaces: addr_space_convert never called

[David Brown]

On 09/11/10 18:45, Georg Lay wrote:

David Brown schrieb:

On 08/11/10 16:59, Georg Lay wrote:

Richard Guenther schrieb:

On Mon, Nov 8, 2010 at 3:39 PM, Georg Lay   wrote:

Hi, I just started playing around with named address spaces for avr.
Besides general space (ram), I introduced a second one, __pgm, which
shall address program memory where also constants may live. avr is
havard architecture, and both program memory and ram start at
address 0.

  From this and the internals on TARGET_ADDR_SPACE_CONVERT I understand
that pointer casting will not work as expected, because that hook will
only get called if the respective address spaces are subsets. However,
neither is space-1 a subset of space-0 nor vice versa (or am I midlead
by internals?)

Is there a way to make it work in the case where the address spaces
are disjoint? Started this morning and everything went smooth until I
started messing around with pointer casts:


[...]


So as of internals doc, named address spaces are not intended to
implement this kind of memory?


If they are not subsets of each other how'd you convert a pointer
pointing into one to point into the other address-space?  I think
the frontend should diagnose this as invalid.


The front end emits warning. However, explicit casts should yield only
a warning if explicit requested.

With subsets relation returning true the code is like that (I changed
the test case to add 5, the there is an additional *addphi).


[...]


This is fine.

However, I am still confused:

"A is a subset of B iff every member of A is alse member of B".

But in this case, an element of ram is not an element of flash nor is
an element of flash an element of ram. Written down as numbers, these
numers are the same, yes, so that information gets encoded in the
machine mode to know what addresses are legal and what instruction
must be used.

Memory is not linearized because that would imply to take the decision
at runtime.


Would be be possible to define a third memory space as "global" memory,
of which both the ram and the flash are subsets?  It is important to
keep ram as the default memory space, but perhaps an artificial global
memory space would let you do  conversions like this safely and without
warnings.

Even better would be if the global memory space could have 24-bit (or
32-bit if necessary) pointers, so that it would actually encompass all
memory, with ram pointers at 0x80 to match the addresses used by the
linker.  It would also make it a lot easier to use the full flash space
on AVR's with more than 64K flash.


The linker has more information becase it sees relocs/symbols/sections
whatever. The compiler doesn't have this info when it has to access
the memory. In the example given above, there are two cases becase the
application like to destinguith between ram and flash, but I think
that case ir rare. In most cases the application known how to handle a
pointer, and users don't want to see LPM/SBRC/LD sequences or even
more in case of multiple byte access.



I agree that users normally know whether data (or a pointer) is in ram 
or flash.  Sometimes, however, it would be nice to be able to use a 
global pointer even if it is less efficient.


But if you can make "const char _pgm msg[]" work in avr-gcc like "const 
char flash msg[]" in IAR's avr compiler, then it will be a huge step 
forward for avr-gcc.  I think the current inconvenience of needing the 
pgm_read_xxx macros is very much an unfortunate necessity of the current 
compiler.





May I say I think it's great that you are looking into this?  Program
space access on the AVR was the first thing I thought of when I heard of
the concept of named address spaces in C.


It's great work that this is part of gcc now! Just remember all the
hacks to get near/far support into a C16x target.

Besides access and pointer size, maybe even thinks like

int __far __atomic x;



"__far" as a memory space makes sense.  It may even make sense to have 
three extra spaces so that (along with __pgm) you can use all the flash 
space in an Mega256, if that is easier or more efficient than using 
24-bit pointers to flash.


I don't think "__atomic" is appropriate for a memory space, however.  I 
don't know if you've read Linus Torvald's rant against "volatile", but 
his point applies here too.  Variables cannot be volatile or atomic in 
themselves - it is /accesses/ that are volatile or atomic (declaring a 
variable to be "volatile" is simply a shorthand for saying that all 
accesses to it should be volatile).


While volatile accesses are fairly cheap, and not /too/ hard to 
understand (though many people misunderstand them), atomic accesses are 
expensive (since they involve disabling interrupts) and hard to 
understand.  Supposing "ax" and "ay" are declared as "int __atomic ax, 
ay".  Should the statement "ax += 2" be atomic?  Should "ax = ay"?  I 
think it is better to stick to the macros in  - they are 
clear and explicit.  An alternative would be to 

Re: define_split

[Michael Meissner]

On Tue, Nov 09, 2010 at 09:38:28AM +0200, roy rosen wrote:
> I still don't understand the difference between your two examples:
> If you write a define_split then whenever during combine it gets into
> a pattern which matches the define_split then it splits.
> 
> What is the difference when writing define_insn_and_split?
> From what I understood from the docs then if there is such an insn
> then the split does not occur so it would simply match it as an insn
> without splitting and at the end would print the #?
> Can you please elaborate?

In the case where you have a define and split, such as:

(define_insn_and_split "fmasf3"
 [(set (match_operand:SF 0 "f_operand" "=f")
   (plus:SF (mult:SF (match_operand:SF 1 "f_operand" "f")
 (match_operand:SF 2 "f_operand" "f"))
(match_operand:SF 3 "f_operand" "f")))
  (clobber (reg:SF ACC_REGISTER))]
 ""
 "#"
 ""
 [(set (match_dup 4)
   (mult:SF (match_dup 1)
(match_dup 2)))
  (set (match_dup 4)
   (plus:SF (match_dup 4)
(match_dup 3)))
  (set (match_dup 0)
   (match_dup 4))]
 "operands[4] = gen_rtx_REG (SFmode, ACC_REGISTER);")

At the end of the combine pass will be an insn with the plus and mult.  This
insn will exist for at least the  if_after_combine, partition_blocks, regmove,
and outof_cfg_layout_mode passes before it is potentially split in the
split_all_insns pass, unless you have a "&& reload_completed" in the test for
the split (second "" in the example above).

The define_insn_and_split is just syntactic sugar.  You could have written this
as:

(define_insn "fmasf3"
 [(set (match_operand:SF 0 "f_operand" "=f")
   (plus:SF (mult:SF (match_operand:SF 1 "f_operand" "f")
 (match_operand:SF 2 "f_operand" "f"))
(match_operand:SF 3 "f_operand" "f")))
  (clobber (reg:SF ACC_REGISTER))]
 ""
 "#")

(define_split
 [(set (match_operand:SF 0 "f_operand" "=f")
   (plus:SF (mult:SF (match_operand:SF 1 "f_operand" "f")
 (match_operand:SF 2 "f_operand" "f"))
(match_operand:SF 3 "f_operand" "f")))
  (clobber (reg:SF ACC_REGISTER))]
 ""
 [(set (match_dup 4)
   (mult:SF (match_dup 1)
(match_dup 2)))
  (set (match_dup 4)
   (plus:SF (match_dup 4)
(match_dup 3)))
  (set (match_dup 0)
   (match_dup 4))]
 "operands[4] = gen_rtx_REG (SFmode, ACC_REGISTER);")

Thus, if you had the following insns before combine:

(insn ... (set (reg:SF 123)
   (mult:SF (reg:SF 124)
(reg:SF 125

(insn ... (set (reg:SF 126)
   (plus:SF (reg:SF 123)
(reg:SF 127

After combine, the combined insn would be (note register 123 disappears after
combine):

(insn ... (set (reg:SF 126)
   (plus:SF (mult:SF (reg:SF 124)
 (reg:SF 125))
(reg:SF 127

The split pass would then break this back into three insns:

(insn ... (set (reg:SF ACC_REGISTER)
   (mult:SF (reg:SF 124)
(reg:SF 125

(insn ... (set (reg:SF ACC_REGISTER)
   (plus:SF (reg:SF ACC_REGISTER)
(reg:SF 127

(insn ... (set (reg:SF 126)
   (reg:SF ACC_REGISTER)))

Now, if you just had the split and no define_insn, combine would try and form
the (plus (mult ...)) and not find an insn to match, so while it had the
temporary insn created, it would try to immediately split the insn, so at the
end of the combine pass, you would have:

(insn ... (set (reg:SF ACC_REGISTER)
   (mult:SF (reg:SF 124)
(reg:SF 125

(insn ... (set (reg:SF ACC_REGISTER)
   (plus:SF (reg:SF ACC_REGISTER)
(reg:SF 127

(insn ... (set (reg:SF 126)
   (reg:SF ACC_REGISTER)))

So whether the passes in between combine and the split pass care, is a
different question.  I didn't recall that combine had this split feature.  As I
said, my preference is to create the insn, and then split it later.

Note, you can only allocate new registers (either hard registers or pseudo
registers) in the split passes before register allocation.  You will get an
error if you create a new register after reload.

-- 
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com

gcc-4.4-20101109 is now available

[gccadmin]

Snapshot gcc-4.4-20101109 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20101109/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch 
revision 166510

You'll find:

 gcc-4.4-20101109.tar.bz2 Complete GCC (includes all of below)

  MD5=77a1f087f1b1eebb1a1f24f53a2c5820
  SHA1=fae6a4d2a395b9bd392149b694e7ee36fafb409f

 gcc-core-4.4-20101109.tar.bz2C front end and core compiler

  MD5=78327705361b99cec8621a9ab265db34
  SHA1=3b7ac769718572e3092bd88c23833b72699d760f

 gcc-ada-4.4-20101109.tar.bz2 Ada front end and runtime

  MD5=f1cb7d57a2a60a158a8b7ba4cd9eaa32
  SHA1=6da740887a803a9f27fb447f137fe845b9ecf332

 gcc-fortran-4.4-20101109.tar.bz2 Fortran front end and runtime

  MD5=751cfb462a488ce51a83748e12254021
  SHA1=5c339798e496a84e055ebf9b01803c8cfe968f26

 gcc-g++-4.4-20101109.tar.bz2 C++ front end and runtime

  MD5=14c8f024f9a40905620da63cf90df278
  SHA1=601448b857941bf9762f58587c2ec448e19f1bb4

 gcc-java-4.4-20101109.tar.bz2Java front end and runtime

  MD5=5b151098760cc0780d2c708ad23bdc1d
  SHA1=4c72adea229e2479afc15aa8f9e1127ba13e6208

 gcc-objc-4.4-20101109.tar.bz2Objective-C front end and runtime

  MD5=d352a245f945fd01e7675fbe3dbb43f1
  SHA1=a2a5c7a7f9d9e98d7ed6ddff663d515a700da86d

 gcc-testsuite-4.4-20101109.tar.bz2   The GCC testsuite

  MD5=9ab0d5635611f4906ca472bef461bc00
  SHA1=bd137c79b7b5c6a98c4712f813857b0e697f6b12

Diffs from 4.4-20101102 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.4
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: define_split

[Michael Meissner]

On Tue, Nov 09, 2010 at 01:38:17PM -0500, Joern Rennecke wrote:
> Quoting Paolo Bonzini :
> 
> >On 11/09/2010 05:38 PM, Joern Rennecke wrote:
> >>A define_insn will be recognized in all contexts.
> >>Having an insn pattern for an insn that does not actually exist can cause
> >>all kinds of unintended consequences as the optimizers try to generate
> >>and recognize 'optimized' patterns, or when reload does its stuff.
> >
> >Before reload that is not a problem at all, I think, actually it can be
> >an advantage.
> 
> No, it is a code quality problem.  And yes, I have seen actual
> SH patterns being recognized that were not wanted, and lead to worse
> code overall.

Generally you need to tighten the pattern conditions to make sure it doesn't
match.

-- 
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com

Re: define_split

[Joern Rennecke]

Quoting Michael Meissner :


So whether the passes in between combine and the split pass care, is a
different question.  I didn't recall that combine had this split  feature.


I remember that it has been there even before the GNU GCC project started
using cvs.  Fortunately, we still have the translated history from RCS
going backeven further... but the earliest mention of find_split_point
in combine.c is shown as having been added in 'revision' 357 - the
same one that combine.c was brought under RCS control, in February 1992.

Re: define_split

[Joern Rennecke]

Quoting Michael Meissner :


Generally you need to tighten the pattern conditions to make sure it doesn't
match.


Sometimes the only sane and effective way of tightening the pattern conditions
is to have an insn condition of "0".
At which point the define_insn_and_split becomes syntactic sugar
(plus starch, guar gum, stabilizers and emulsifiers) for just having a
splitter pattern.

Opinion on a hardware feature for conditional instructions

[Mohamed Shafi]

Hi all,

I need a opinion on a design front. I am doing a port for a private
target in GCC 4.5.1. We are also in the process of designing the
hardware along with the development of the build tools. Currently we
don't have enough bits in the encoding to support conditional
instruction like arm does. i.e. you have the option to decide whether
to update the status flags or not. So what is the next best thing to
have?

1. Allow both conditional and non-conditional instructions to update
the status flags
2. Allow only non-conditional instructions to update the status flags

Could you please let me know your thoughts on this and the reason for
choosing it?

Regards,
Shafi