Quoting Joern Rennecke :
Right now, to make a new target hook, you have to add a new field in
target.h, define a new default in target-def.h, place the new macro
in exactly the right position there of the right initializer macro,
describe the new hook in tm.texi, and if you need a new function wi
> -Original Message-
> From: Andrew Hutchinson [mailto:andrewhutchin...@cox.net]
> Sent: Wednesday, December 23, 2009 3:25 PM
> To: Denis Chertykov; Anatoly Sokolov; GCC Development;
> Weddington, Eric
> Subject: Approval as AVR maintainer
>
> How does one get to be maintainer of port
How does one get to be maintainer of port?
Specifically AVR port - so that I do not need to get approval to commit
changes. The time it takes now is rather longer than getting approval on
other parts of GCC.
The process does not seem to be written down anywhere - but I am sure
someone will c
Hi,
After the tree-loop pass, I need to perform some analysis on the loop
and insert a "gimple function call statement" before the loop body.
The function call looks like,
foo(a, 1, 1); for a loop that looks like,
for (i = 0; i < 20; i ++) {
a[i]++;
}
When compiled with -O2, after the tree
Paolo Bonzini wrote:
I think that if you add the simplification to simplify-rtx.c's
simplify_subreg, combine should pick it up automagically.
Paolo
There we have it! There is apparently already this optimization
performed - so I will have to dig further into why it does not a happen.
Similar situation happens in non loop context as well. PRE commoned
address computation without knowing the existence of advanced
addressing mode, which result in unnecessary address computation
instruction. The forward substitution code makes local heuristics and
looks at each use individually --
On Wed, Dec 23, 2009 at 10:06 AM, Paolo Bonzini wrote:
> On 12/23/2009 06:47 PM, H.J. Lu wrote:
>>
>> On Wed, Dec 23, 2009 at 8:41 AM, Paolo Bonzini wrote:
>>>
>>> On 12/23/2009 04:19 PM, Bingfeng Mei wrote:
It seems that just commenting out this check in fwprop.c should work.
>>>
>>> Y
On 12/23/2009 06:47 PM, H.J. Lu wrote:
On Wed, Dec 23, 2009 at 8:41 AM, Paolo Bonzini wrote:
On 12/23/2009 04:19 PM, Bingfeng Mei wrote:
It seems that just commenting out this check in fwprop.c should work.
Yes, but it would pessimize x86.
Is there a bug open for x86? Can't we make it ta
On Wed, Dec 23, 2009 at 8:41 AM, Paolo Bonzini wrote:
> On 12/23/2009 04:19 PM, Bingfeng Mei wrote:
>>
>> It seems that just commenting out this check in fwprop.c should work.
>
> Yes, but it would pessimize x86.
>
Is there a bug open for x86? Can't we make it target dependent, something
like
/
Doh!
Joseph S. Myers wrote:
On Wed, 23 Dec 2009, Andrew Hutchinson wrote:
builtin_define_std
cpp_define
Both from c-cppbuiltin.c. These have no prototypes defined in gcc.
They do have prototypes, in c-common.h and cpplib.h.
On 12/23/2009 04:19 PM, Bingfeng Mei wrote:
It seems that just commenting out this check in fwprop.c should work.
Yes, but it would pessimize x86.
Paolo
On Wed, 2009-12-23 at 16:00 +0100, Paolo Bonzini wrote:
> On 12/23/2009 03:27 PM, Bingfeng Mei wrote:
> > Do you mean if TARGET_ADDRES_COST (non-x86) is defined properly,
> > this should be fixed? Or it requires extra patch?
>
> No, if TARGET_ADDRESS_COST was fixed for x86 (and of course defined
On Wed, 23 Dec 2009, Andrew Hutchinson wrote:
> builtin_define_std
> cpp_define
>
> Both from c-cppbuiltin.c. These have no prototypes defined in gcc.
They do have prototypes, in c-common.h and cpplib.h.
--
Joseph S. Myers
jos...@codesourcery.com
It seems that just commenting out this check in fwprop.c should work.
/* Do not propagate loop invariant definitions inside the loop. */
/* if (DF_REF_BB (def)->loop_father != DF_REF_BB (use)->loop_father)
return;*/
Bingfeng
> -Original Message-
> From: Paolo Bonzini [mailto:paol
Target hooks would often be interesting for plugins to modify. And
some proposed new plugin callbacks would also be interesting to have as
target hooks. Therefore, I would like target hooks to become writeable
by plugins, and make it much easier to add new target hooks in the GCC
sources.
Right
On 12/23/2009 03:27 PM, Bingfeng Mei wrote:
Do you mean if TARGET_ADDRES_COST (non-x86) is defined properly,
this should be fixed? Or it requires extra patch?
No, if TARGET_ADDRESS_COST was fixed for x86 (and of course defined
properly for your target), we could fix this very easily.
Paolo
On Tue, Dec 22, 2009 at 11:47, Aravinda wrote:
> Is this is the only way it can be done ? Or can I have
> (non-temporary)variables inserted whos order can be preserved always ?
Not really, the compiler will reorder variables in the stack in almost
arbitrary ways. Wrapping them in structs is the
Do you mean if TARGET_ADDRES_COST (non-x86) is defined properly,
this should be fixed? Or it requires extra patch?
Bingfeng
> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On
> Behalf Of Paolo Bonzini
> Sent: 23 December 2009 13:28
> To: Steven Bosscher
> Cc
On 12/23/2009 03:05 PM, Joern Rennecke wrote:
So if this is only useful for a limited set of targets, why isn't it
controlled by an option or a target hook so that it is only turned on
on the targets where it is deemed to make sense overall?
Well, this optimization is basically the opposite of
Quoting Paolo Bonzini :
On 12/23/2009 01:01 PM, Steven Bosscher wrote:
On Wed, Dec 23, 2009 at 12:49 PM, Bingfeng Mei wrote:
Hello,
I encounter an issue with PRE optimization, which created worse
Is this at -O2 or -O3?
I think this could be fixed if fwprop propagated addresses into loops;
On 12/23/2009 01:01 PM, Steven Bosscher wrote:
On Wed, Dec 23, 2009 at 12:49 PM, Bingfeng Mei wrote:
Hello,
I encounter an issue with PRE optimization, which created worse
Is this at -O2 or -O3?
I think this could be fixed if fwprop propagated addresses into loops;
it doesn't because it ma
I want to post patch for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42457
The code moved out to -c.c file ALREADY uses:
builtin_define_std
cpp_define
Both from c-cppbuiltin.c. These have no prototypes defined in gcc.
So of course there are warnings emitted.
Is this OK?
Should I locally defi
-O2
> -Original Message-
> From: Steven Bosscher [mailto:stevenb@gmail.com]
> Sent: 23 December 2009 12:01
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org; dber...@dberlin.org
> Subject: Re: Unnecessary PRE optimization
>
> On Wed, Dec 23, 2009 at 12:49 PM, Bingfeng Mei
> wrote:
> > Hell
On Wed, Dec 23, 2009 at 12:49 PM, Bingfeng Mei wrote:
> Hello,
> I encounter an issue with PRE optimization, which created worse
Is this at -O2 or -O3?
Ciao!
Steven
Hello,
I encounter an issue with PRE optimization, which created worse
code than no optimization.
This the test function:
void foo(int *data, int *m_v4w, int num)
{
int i;
int m0;
for( i=0; i
On 12/23/2009 06:12 PM, Dave Korn wrote:
Jie Zhang wrote:
typedef unsigned short u16;
typedef unsigned int u32;
u32 a(volatile u16* off) {
return *off;
}
mingw32-gcc-4.3.0.exe -c -O2 -fomit-frame-pointer -mtune=core2 test.c
it produces:
<_a>:
0: 8b 44 24 04
On Wed, 2009-12-23 at 10:11 +0530, Mohamed Shafi wrote:
> 2009/12/22 Richard Earnshaw :
> >
> > On Mon, 2009-12-21 at 18:44 +, Paul Brook wrote:
> >> > > > I am doing a port in GCC 4.4.0 for a 32 bit target. As a part of
> >> > > > scheduling framework i have to write the move patterns with mo
Jie Zhang wrote:
> typedef unsigned short u16;
> typedef unsigned int u32;
>
> u32 a(volatile u16* off) {
> return *off;
> }
> mingw32-gcc-4.3.0.exe -c -O2 -fomit-frame-pointer -mtune=core2 test.c
>
> it produces:
> <_a>:
>0: 8b 44 24 04 mov0x4(%esp),%eax
On 12/22/2009 07:24 PM, Jeff Law wrote:
On 12/22/09 11:16, Andrew Hutchinson wrote:
I came across this RTL on AVR in combine dump (part of va-arg-9.c test)
(set (reg:QI 25 r25 [+1 ])
(subreg:QI (sign_extend:HI (reg:QI 49)) 1))
The sign extension is completely redundant - the upper part of
regi
On 12/23/2009 02:43 PM, Jie Zhang wrote:
Hi,
We just got a similar problem on Blackfin GCC recently. Let me take the
test code from the bug as an example:
I reduce the test case to a simpler one:
$ cat foo.c
unsigned int
foo (volatile unsigned short *p)
{
return *p;
}
I the tree dump "foo.
On 12/21/2009 08:10 PM, Richard Henderson wrote:
(define_insn_and_split "*cmp"
[(set (match_operand:SI 0 "register_operand" "=r")
(lt:SI (match_operand:SI 1 "register_operand" "r")
(match_operand:SI 2 "register_operand" "r")))]
""
"cmp %0,%1,%2\;andi $0,$0,1"
31 matches
Mail list logo
