Attached please find the patch of our initial prototype of GCC plugin
support based on the APIs described in the (old) wiki page. I also
attached a sample plugin program (dumb-example.c) that shows how a
plugin uses the APIs.
Sean and Taras (and others),
Diego will be creating a branch for the pl
Le-Chun Wu wrote:
Hi Sean,
It's great that you updated the wiki page with the latest and more
detailed API design.
We (at Google) also started to look at the GCC plugin support a couple
of weeks ago. We had a quick prototype implemented based on the
original APIs that Taras put together in the
Snapshot gcc-4.3-20090205 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090205/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Jean Christophe Beyler writes:
> I'm currently working on removing the constant folding and constant
> propagation because, on the architecture I'm working on, it is highly
> costly to move a constant into a register if the number is big (we can
> say over 16 bits).
>
> Currently, I've been looki
True but what I've noticed with GCC 4.3.2 is that with this code:
#include
#include
int main(void)
{
long a = 0xcafecafe;
printf("Final: %lx %lx %lx\n", a, a+5, a+15);
return EXIT_SUCCESS;
}
Whether I compile it with a big number like here or a smaller number,
I'll get something l
On Thu, Feb 05, 2009 at 12:46:01PM -0800, Joe Buck wrote:
> On Thu, Feb 05, 2009 at 12:34:14PM -0800, Jean Christophe Beyler wrote:
> > I'm currently working on removing the constant folding and constant
> > propagation because, on the architecture I'm working on, it is highly
> > costly to move a
On Thu, Feb 05, 2009 at 12:34:14PM -0800, Jean Christophe Beyler wrote:
> I'm currently working on removing the constant folding and constant
> propagation because, on the architecture I'm working on, it is highly
> costly to move a constant into a register if the number is big (we can
> say over 1
Dear all,
I'm currently working on removing the constant folding and constant
propagation because, on the architecture I'm working on, it is highly
costly to move a constant into a register if the number is big (we can
say over 16 bits).
Currently, I've been looking into this and it seems that I
On Sun, 2009-02-01 at 22:45 +0100, Laurent GUERBY wrote:
> Thanks for the link!
>
> This confirms that all pch test fail on mipsel, from the first
> to the last log available on your site:
>
> http://people.debian.org/~doko/tmp/gcc-mips/gcc-snapshot_20080523-1_mipsel.bz2
> http://people.debian.or
Yoriko Komatsuzaki writes:
> Could you tell me why it doesn't work well around FRAME_GROWS_DOWNWARD
> on mips ?
I have a WIP patch for this but was holding back mostly because of stage3/4
and that I was trying to make FRAME_GROWS_DOWNWARD the default and I was
running into performance issues.
Th
On Thu, Feb 5, 2009 at 5:59 AM, Ben Elliston wrote:
> On Tue, 2009-02-03 at 01:59 -0500, Sean Callanan wrote:
>
>> Our plugins do not break when switching compiler binaries. In fact, I
>> have had plug-in binaries that perform very simple tasks work fine
>> when switching (minor!) compiler releas
On Fri, Feb 06, 2009 at 12:30:13AM +1100, Zoltán Kócsi wrote:
> Almost the same:
>
> x86_64: 4.0.2
> AVR:4.0.1
> ARM:4.0.2
>
> So, at least the Intel and the ARM are the same yet the Intel version
> omits the .rodata, the ARM keeps it. I'll check it with the newer
> version next wee
On Thu, Feb 5, 2009 at 3:04 PM, Paul Brook wrote:
>> Hmm, we should be able to model this counting the number of edges
>> bypassing the call, right?
>
> Something like that, yes.
>
> Ideally you'd want to factor in the size of the function, and the current
> length of those edges, at which point y
> > On Thumb-2 we found that the overhead of a function call was often
> > smaller than the cost of lengthening branches in the caller.
> > It turns out that, over a fair selection of applications, programmers
> > tend to write "nice" sized functions. After inlining we have big nasty
> > blocks of
On Thu, 5 Feb 2009, Paul Brook wrote:
> > For -Os it should be enough to set PARAM_STACK_FRAME_GROWTH
> > to zero. Inlining at -Os should already only happen if it decreases
> > (overall!) code-size. Thus, inlining a function that is called once and
> > that does not need to be emitted will alwa
> For -Os it should be enough to set PARAM_STACK_FRAME_GROWTH
> to zero. Inlining at -Os should already only happen if it decreases
> (overall!) code-size. Thus, inlining a function that is called once and
> that does not need to be emitted will always be an overall code-size
> win.
>
> > A side
On Thu, 5 Feb 2009 10:58:40 -0200
Alexandre Pereira Nunes wrote:
> On Wed, Feb 4, 2009 at 11:05 PM, Zoltán Kócsi
> wrote: [cut]
> >
> > If I compile the above with -O2 or -Os, then if the target is AVR or
> > x86_64 then the result is what I expected, func() just loads 3 or
> > 12345 then return
On Wed, Feb 4, 2009 at 11:05 PM, Zoltán Kócsi wrote:
[cut]
>
> If I compile the above with -O2 or -Os, then if the target is AVR or
> x86_64 then the result is what I expected, func() just loads 3 or 12345
> then returns and that's all. There is no .rodata generated.
>
> However, compiling for th
On Tue, 2009-02-03 at 01:59 -0500, Sean Callanan wrote:
> Our plugins do not break when switching compiler binaries. In fact, I
> have had plug-in binaries that perform very simple tasks work fine
> when switching (minor!) compiler releases.
Thinking about this made me realise that the plugi
Hello
I would like to use -fstack-protector in mips.
But mips stack protector seems not to be supported.
I think that the macro FRAME_GROWS_DOWNWARD should be defined for stack
protector working. And mips does'nt define this macro.
To define this macro, the addresses of local variable slots are
20 matches
Mail list logo
