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
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
On Tue, 14 Sep 2010, Steven Bosscher wrote:
On Tue, Sep 14, 2010 at 5:39 PM, Marcus Daniels mdani...@lanl.gov 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
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
On Tue, Sep 14, 2010 at 3:36 PM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
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
On Tue, Sep 14, 2010 at 09:36, Basile Starynkevitch
bas...@starynkevitch.net 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
On Tue, Sep 14, 2010 at 3:36 PM, Basile Starynkevitch
bas...@starynkevitch.net 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 10:12:18AM -0400, Diego Novillo wrote:
On Tue, Sep 14, 2010 at 09:36, Basile Starynkevitch
bas...@starynkevitch.net 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 for the
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
On Tue, Sep 14, 2010 at 5:39 PM, Marcus Daniels mdani...@lanl.gov 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
On Tue, 14 Sep 2010 09:39:21 -0600
Marcus Daniels mdani...@lanl.gov 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
On Tue, 14 Sep 2010 16:01:34 +0200
Richard Guenther richard.guent...@gmail.com wrote:
But is the overall idea enough, or did I misunderstood builtins?
Builtins use a fixed code (in DECL_FUNCTION_CODE) and have
a class (BUILT_IN_MD, BUILT_IN_NORMAL, etc.). Thus without
making the code
On 9/14/10 10:58 AM, Basile Starynkevitch wrote:
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 #pragma-s builtin-s attributes for these. This is why I was
trying to push the idea of
On Tue, 14 Sep 2010 11:21:51 -0600
Marcus Daniels mdani...@lanl.gov wrote:
On 9/14/10 10:58 AM, Basile Starynkevitch wrote:
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 #pragma-s
On Tue, Sep 14, 2010 at 15:22, Basile Starynkevitch
bas...@starynkevitch.net 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
On Tue, 14 Sep 2010 16:40:59 -0400
Diego Novillo dnovi...@google.com 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
On Tue, Sep 14, 2010 at 16:48, Basile Starynkevitch
bas...@starynkevitch.net wrote:
Is it becoming a GC or gengtype reviewer?
Yes.
Diego.
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 Gimple,
2010/9/14 Diego Novillo dnovi...@google.com:
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
19 matches
Mail list logo
