result of the plugin API discussion at
the GCC summit.
Taras
Joseph S. Myers wrote:
On Mon, 6 Oct 2008, Taras wrote:
http://gcc.gnu.org/wiki/GCC_PluginAPI
I put up an API proposal. It's a result of the plugin API discussion at the
GCC summit.
I believe the API also needs interfaces for verifying compatibility
(exporting the require
nnotations elsewhere in the code,
so the system should be improved, not canned.
Taras
On Wed, Jun 25, 2008 at 10:49 AM, Tom Tromey <[EMAIL PROTECTED]> wrote:
"Daniel" == Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
On Wed, Jun 25, 2008 at 08:35:41AM -0600
nnotations elsewhere in the code,
so the system should be improved, not canned.
Taras
On Wed, Jun 25, 2008 at 10:49 AM, Tom Tromey <[EMAIL PROTECTED]> wrote:
"Daniel" == Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
On Wed, Jun 25, 2008 at 08:35:41AM -0600
UNCTION(t) - but that
doesn't work now either. Working copy of my patches is available for
your reference at http://necago.ic.cz/prj/scc/
We support this sort of thing in Mozilla's Treehydra gcc plugin. See
http://developer.mozilla.org/en/docs/Treehydra
In addition to cfg you can get much other stuff such as types.
Taras
the resulting binary to do LTO-style analyses. How well is that working
for you?
Taras
cc as well.
In our case, plugin users do no need the sources, they just need a
binary for the compiler and the plugin which can be provided by their
package manager.
Cheers,
Taras
their bug reporting tool not being able to do unwind
info for split functions.
Taras, do you have any data if the partitioning helps?
Honza
Currently it does not help. I believe it has potential since we have a
lot of large methods where only a small part of them gets run.
Taras
Grigori Fursin wrote:
Thanks, Taras!
I slightly updated this page, i.e. we would like to be able to load plugins
through environment variables to be able to optimize programs transparently
as it is done in MILEPOST GCC (without Makefile modifications). By the way,
we plan to extend the
ossible that these
handlers might need to return an integer value, but so far in my plugin
work I have not needed that so I didn't include return values in the
proposal.
Taras
fields to be used as outparams(I like this idea as it means no
changes are needed :)?
Taras
/Treehydra
Great to see that others independantly identified need for the same
functionality. Hopefully the patch will go into the next development cycle.
Taras
Cheers,
Cupertino
On Oct 10, 2008, at 4:14 PM, Grigori Fursin wrote:
I currently don't have any preference for a specific w
important
that we agree on an API so that every group can easily port their
plugins to it.
Indeed. As a maintainer of a couple gcc plugins and a corresponding API,
what can I do to help out?
Taras
https://developer.mozilla.org/En/Dehydra
ra
However any formalization should make my life easier.
Sean, I agree with you and I think others will too, so please go ahead
and make your API modifications on the wiki
Taras
call. The plugin should check the gcc version it is
being loaded into on startup and bail if it doesn't match.
Taras
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 i
to support
"experimental" plugins by the beginning of next week. In the mean time, would like to know your
thoughts on that matter and how should we proceed forward !..
Like I said, I don't think the communities are as distinct as you are
implying.
Cheers,
Taras
/GCC_PluginAPI
We do this sort of thing in Mozilla with stuff like
https://developer.mozilla.org/En/Dehydra.
Taras
plugins running into this issue?
Taras
Diego Novillo wrote:
On Tue, Jun 9, 2009 at 15:33, Taras Glek wrote:
While developing my plugin I've noticed that many callbacks need to be
guarded with "if (errorcount)" or the plugin will cause a gcc crash due to
receiving less complete data than it expected.
More
stall-plugin target.
Now I'm stuck, it's not clear to me how to call my new target from
Makefile.in properly. In the attachment, I call it as a dependency on
install-plugin, but that's obviously hack. Can someone suggest a proper
way to do this?
Thanks,
Taras
diff --git a/g
switchover to 4.5.
I'm not sure how to proceed from here,
Taras
On 06/24/2010 12:06 PM, Andrew Pinski wrote:
On Jun 24, 2010, at 11:50 AM, Taras Glek wrote:
Hi,
Just wanted to give a heads up on what might be the biggest
compiler-upgrade-related performance difference we've seen at Mozilla.
We switched gcc4.3 for gcc4.5 and our automated benchma
On 06/30/2010 02:26 PM, Basile Starynkevitch wrote:
On Wed, 2010-06-30 at 14:23 -0700, Taras Glek wrote:
I tried 4.5 -O2 and it's actually faster than 4.3 -Os.
I am happy that -O2 performance is actually pretty good, but -Os
regression is going to hurt on mobile.
Did you try gc
On 06/30/2010 03:06 PM, Jan Hubicka wrote:
If you can find actual simple examples where -Os is losing size and speed we
can try
to do something about them.
According to our code size reports, inlining is completely screwed for
C++ wrapper classes like ones often used for smart pointers, arr
On 07/01/2010 02:27 PM, Richard Guenther wrote:
On Thu, Jul 1, 2010 at 10:29 PM, Taras Glek wrote:
On 06/30/2010 03:06 PM, Jan Hubicka wrote:
If you can find actual simple examples where -Os is losing size and speed
we can try
to do something about them.
According to our code size reports
On 07/01/2010 02:45 PM, Richard Guenther wrote:
On Thu, Jul 1, 2010 at 11:36 PM, Taras Glek wrote:
On 07/01/2010 02:27 PM, Richard Guenther wrote:
On Thu, Jul 1, 2010 at 10:29 PM, Taras Glekwrote:
On 06/30/2010 03:06 PM, Jan Hubicka wrote:
If you can find actual simple examples where
manifestation of the major issue:
typedef int* pint;
pint foo; <-- type_as_string(type, 0) returns "int*"
Is the following behavior intentional?
typedef int t1;
class c{
typedef t1 t2;
t2 v; <-- type_as_string returns "t1".
};
Thanks,
Taras
More info on my plugin: http://wiki.mozilla.org/Dehydra_GCC
u be willing to accept such a change?
Another possible benefit of raising GTYs to attribute status would be
that other projects could do compile-time reflection similar to what GCC
does in a semi-formal way.
Thanks,
Taras
ps. For more info on my plugin see http://wiki.mozilla.org/Dehydra_GCC
e and combine our efforts to push this upstream(or at
least into Linux distributions)
The homepage for my plugin work is:
http://wiki.mozilla.org/Dehydra_GCC
See my blog for more details http://blog.mozilla.com/tglek
I'm looking forward to hearing from you.
Taras
Grigori Fursin wrot
ing acceptable
and submit stuff for review.
See http://developer.mozilla.org/en/Dehydra for more details on
Mozilla's plugin work.
Cheers,
Taras
local. Someone could write a helper library to make it
relatively simple to hook in. But... I looked at this recently, and
since gcc is not linked with -rdynamic, it is a non-starter.
Tom, I don't know much about linkers and LD_PRELOAD. Would making
LD_PRELOAD work be easier than making an unstable plugin API?
Taras
32 matches
Mail list logo
