On Tue, 14 Sep 2010, Steven Bosscher wrote:
> On Tue, Sep 14, 2010 at 5:39 PM, Marcus Daniels wrote:
> > On 9/14/10 8:46 AM, Basile Starynkevitch wrote:
> >>
> >> My current work aims to translate some Gimple into OpenCL source
> >> code, thus providing GCC with the ability to take advantage of
On 09/15/2010 08:54 AM, Arnaud Charlet wrote:
Given the current limitations of Gimple, another area to focus on could be
task parallelism (rather than data parallelism). In that case a language
like [Google] Go (via GCC) might make a better talking point than C or
Fortran.
An even better start
> Given the current limitations of Gimple, another area to focus on could be
> task parallelism (rather than data parallelism). In that case a language
> like [Google] Go (via GCC) might make a better talking point than C or
> Fortran.
An even better starting point would be Ada which has built-in
2010/9/14 Diego Novillo :
> Incidentally, this is an issue I would like to address. We need
> someone interested in maintaining the GC machinery. Any volunteers?
> Laurynas?
Thanks for the suggestion. In fact, I was meaning to apply. But I can
see a few things that need to be considered:
- Most
> The GCC middle end use is for me mandatory (since it is contractual). I
> am expecting to work on Gimple to OpenCL translation, whatever that
> means. The saling point it that starting from GCC & gimple gives the
> hypothetical enduser all the power of GCC.
Given the current limitations of Gimp
On Tue, Sep 14, 2010 at 16:48, Basile Starynkevitch
wrote:
> Is it becoming a GC or gengtype reviewer?
Yes.
Diego.
On Tue, 14 Sep 2010 16:40:59 -0400
Diego Novillo wrote:
>
> Incidentally, this is an issue I would like to address. We need
> someone interested in maintaining the GC machinery. Any volunteers?
> Laurynas?
What do you mean by "maintaining the GC machinery"?
What is not working in the current
On Tue, Sep 14, 2010 at 15:22, Basile Starynkevitch
wrote:
> I'm just trying to figure out what are the features in 4.6 which will
> be useful to my work. I know that in a couple of weeks, they are frozen
> (since 4.6 is ending stage 1). The gengtype patch series
No. End of October.
> http://g
, etc
> > One can use #pragma-s& builtin-s& attributes for these. This is why I was
> > trying to push the idea of plugin hooks for builtins.
> In this use case, what is the GCC middle-end *for* if it does not
> understand data parallel operations? Even GENERIC lacks the
g to push the idea of plugin hooks for builtins.
In this use case, what is the GCC middle-end *for* if it does not
understand data parallel operations? Even GENERIC lacks the notion,
right? (We've been working directly from the Fortran parse tree.)
Marcus
gning dynamic this won't work.
>
> > Could such a small patch be accepted before end of stage 1?
>
> No. We don't want new plugin hooks without an implemented use-case.
What exactly is an implemented use-case? Is it just a test code? Or is
it an entire big 20KLOC plugin de
ding French government
> > agencies) to work on anything close to the target processor or silicon
> > in GCC.
> It seems to me a "source to source" compiler should definitely retain
> high level constructs like array operators, DO ALL, OpenMP directives, etc.
One can use
On Tue, Sep 14, 2010 at 5:39 PM, Marcus Daniels wrote:
> On 9/14/10 8:46 AM, Basile Starynkevitch wrote:
>>
>> My current work aims to translate some Gimple into OpenCL source
>> code, thus providing GCC with the ability to take advantage of GPU
>> running their proprietary OpenCL compilers with
On 9/14/10 8:46 AM, Basile Starynkevitch wrote:
My current work aims to translate some Gimple into OpenCL source
code, thus providing GCC with the ability to take advantage of GPU
running their proprietary OpenCL compilers without asking the user to
learn OpenCL.
My understanding is that Gimpl
On Tue, Sep 14, 2010 at 10:12:18AM -0400, Diego Novillo wrote:
> On Tue, Sep 14, 2010 at 09:36, Basile Starynkevitch
> wrote:
>
> > I was thinking of adding a new plugin hook for builtins.
> Plugin hooks should only be added when an actual need arises. Adding
> hooks f
Hello All
See also my message http://gcc.gnu.org/ml/gcc/2010-09/msg00270.html
about plugin hooks for plugin-provided builtins?
I was thinking of adding a new plugin hook for plugin-provided
additional macros.
The intuition is that some plugins would be delighted if they could
add their own
On Tue, Sep 14, 2010 at 3:36 PM, Basile Starynkevitch
wrote:
> I was thinking of adding a new plugin hook for builtins.
Shouldn't there be a final consensus about the existing hooks, and
actual users of them, before adding more and more and more plugin
hooks?
Ciao!
Steven
On Tue, Sep 14, 2010 at 09:36, Basile Starynkevitch
wrote:
> I was thinking of adding a new plugin hook for builtins.
We need to have a good use case before adding any more plugin hooks.
In the case of this proposal, you also need a fixed code and a class
for the builtins to work.
In gene
ore);
> }
>
>
> I actually intend to code something more flexible, by having plugin
> able to register a builtin expanding function with some client data.
>
> But is the overall idea enough, or did I misunderstood builtins?
Builtins use a fixed code (in DECL_FUNCTION_CODE) and
Hello All,
I was thinking of adding a new plugin hook for builtins.
The intuition is that some plugins could be pleased if they could add
their own plugins (much like today's plugins can add their own pragmas
or attributes).
I imagine several use cases for such a feature, for example
* a buil
rd Guenther'; 'Basile STARYNKEVITCH'; 'Ian
> Lance Taylor'; 'GCC
> Mailing List'; 'Albert Cohen'; ctuning-discussi...@googlegroups.com; Yuri
> Kashnikoff
> Subject: RE: plugin hooks
>
> Quoting Grigori Fursin :
> > Also, I hope
Quoting Grigori Fursin :
Also, I hope that we will start collaborating with Joern Rennecke in
a few weeks to update the ICI
and GSOC'09
developments based on the recent feedback to see if we can move it
to the mainline ...
We still need a branch name for that. Since GCC is currently in
Richard Guenther wrote:
On Wed, Oct 28, 2009 at 8:34 PM, Basile STARYNKEVITCH
wrote:
I really think we should add more plugin hooks *now* for gcc-4.5. They
really cannot wait the future 4.6 release (in 2011, 2012?), especially since
I don't agree at all. Also I have the feeling
t time which will use a
> PLUGIN_REGISTER_PRAGMA. If I requires its users to compile a gcc-trunk
> (since only after mid 2010 will I be able to really demonstrate a valid use
> of PLUGIN_REGISTER_PRAGMA), nobody -I really think not a single person- will
> use my plugin. If my plugin run
ince only after mid 2010 will I be able to really demonstrate a valid
use of PLUGIN_REGISTER_PRAGMA), nobody -I really think not a single
person- will use my plugin. If my plugin runs on a standard 4.5 binary
distribution of gcc, I might have a few users!
I really think we should add more pl
> From several face to face discussions with ICI CTuning people (that it
> Grigori Fursin, Albert Cohen, Zbignew Chamski; all 3 are in CC of this
> reply) I understood that GCC ICI is exactly doing that: it has replaced GCC
> pass manager by its own, which invokes all the existing GCC passes in som
> I believe there is a strong chicken & egg issue here. Ian is suggesting that
> hooks should be added only when an existing plugin would need them, but I
> believe that on the contrary plugins won't appear if they don't have a
> sufficient set of hooks. People won't even bother to make plugins if
> We should add hooks as we find plugins that need them. Simply adding
> a laundry list of hooks that we think might be needed will most likely
> cause us to overdesign. We know that we can write interesting plugins
> today, so we're not missing anything critical.
>
> I agree that it should be OK
Hello All
Basile STARYNKEVITCH wrote:
Ian Lance Taylor wrote:
Basile STARYNKEVITCH writes:
* propose a simple patch to add the PLUGIN_REGISTER_PRAGMA event now?
Do this.
Will do probably tommorow or this evening!
I already did sent an initial proposal for the patch.
http://gcc.gnu.org
On Tue, Oct 27, 2009 at 4:48 PM, Basile STARYNKEVITCH
wrote:
> Richard Guenther wrote:
>>
>> The fix is not to add a hook to replace the pass manager but instead
>> to make the GCC pass manager more flexible itself.
>
> I leave that task to my ICI friends (in CC). They have already an
> implementa
On Tue, 27 Oct 2009, Basile STARYNKEVITCH wrote:
> I (Basile) don't know much of libcpp. If a plugin can just call cpp_define,
> this is ok for me. But then, we perhaps should document how can that be
> called, and when (at plugin initialization, at PLUGIN_START_UNIT? I don't
> know!)
A plugin ca
Richard Guenther wrote:
The fix is not to add a hook to replace the pass manager but instead
to make the GCC pass manager more flexible itself.
I leave that task to my ICI friends (in CC). They have already an
implementation, and I believe they probably did propose some patches, or
are worki
On Tue, Oct 27, 2009 at 4:06 PM, Basile STARYNKEVITCH
wrote:
> Ian Lance Taylor wrote:
>>
>> Basile STARYNKEVITCH writes:
>>
>>> * propose a simple patch to add the PLUGIN_REGISTER_PRAGMA event now?
>>
>> Do this.
>
> Will do probably tommorow or this evening!
>>
>> On the other hand, skimming yo
Ian Lance Taylor wrote:
For something like PLUGIN_ADD_CPP_MACROS, the need is clear, but I
think it's an open question we should add a hook or whether the plugin
should just call cpp_define. A hook means that we promise to always
have a way to do this in case cpp_define changes. How do we deci
Ian Lance Taylor wrote:
Basile STARYNKEVITCH writes:
* propose a simple patch to add the PLUGIN_REGISTER_PRAGMA event now?
Do this.
Will do probably tommorow or this evening!
On the other hand, skimming your list of hooks, I really question the
need for, e.g., REPLACE_PASS_MANAGER. I wo
Basile STARYNKEVITCH writes:
> Ian Lance Taylor wrote:
>> We should add hooks as we find plugins that need them. Simply adding
>> a laundry list of hooks that we think might be needed will most likely
>> cause us to overdesign. We know that we can write interesting plugins
>> today, so we're no
Hello All,
Richard Guenther wrote:
Adding hooks just because you think they might be useful
isn't the way to go.
Basile STARYNKEVITCH writes:
Then what is the correct way to enhance the current plugin API. There
are a lot of stuff missing there.
Ian Lance Taylor wrote:
We should add
Basile STARYNKEVITCH writes:
> Richard Guenther wrote:
>> On Tue, Oct 27, 2009 at 1:15 PM, Basile STARYNKEVITCH
>>
>> Adding hooks just because you think they might be useful
>> isn't the way to go.
>
> Then what is the correct way to enhance the current plugin API. There
> are a lot of stuff mis
Richard Guenther wrote:
On Tue, Oct 27, 2009 at 1:15 PM, Basile STARYNKEVITCH
Adding hooks just because you think they might be useful
isn't the way to go.
Then what is the correct way to enhance the current plugin API. There
are a lot of stuff missing there.
I am not at all sure that all t
On Tue, Oct 27, 2009 at 1:15 PM, Basile STARYNKEVITCH
wrote:
> Hello All,
>
> I feel that the current plugin hooks, that is the set of plugin events
> enumerated in the enum plugin_event of gcc/gcc-plugin.h and the associated
> API in gcc/plugin.h (e.g. register_attribute) i
Hello All,
I feel that the current plugin hooks, that is the set of plugin events
enumerated in the enum plugin_event of gcc/gcc-plugin.h and the
associated API in gcc/plugin.h (e.g. register_attribute) is perhaps
still incomplete.
My feeling is that adding plugin events (at least those for
41 matches
Mail list logo
