Ways to add source annotations to a loop
Hello,
I am looking for a way to implement source annotation (or something
similar) for a for loops. Basically, I need some mechanism to mark
certain for loops in the source code for the GIMPLE optimization
passes (for C/C++ only currently).
For example something like this:
int i;
__attribute__((marked)) // Not compilable by GCC.
for (i =0; i < 100; i++) {
foo (i);
}
or
int i;
#pragma marked // Can be compiled, but require additional GIMPLE tree nodes.
for (i =0; i < 100; i++) {
foo (i);
}
As far as I know, for loops are lowered to jumps by C front-end and
natural loops are detected later, so there is no strait way of passing
such information.
OpenMP pragmas provides such functionality, but require additional
GIMPLE nodes to be defined and carried through all optimization
passes,
which I would prefer to avoid (if possible). So, is there any strait
way to implement this?
Best regards,
Alexey
Re: Ways to add source annotations to a loop
On Mon, Dec 3, 2012 at 11:05 AM, Alexey Kravets wrote:
> Hello,
> I am looking for a way to implement source annotation (or something
> similar) for a for loops. Basically, I need some mechanism to mark
> certain for loops in the source code for the GIMPLE optimization
> passes (for C/C++ only currently).
> For example something like this:
>
> int i;
> __attribute__((marked)) // Not compilable by GCC.
> for (i =0; i < 100; i++) {
>foo (i);
> }
>
> or
>
> int i;
>
> #pragma marked // Can be compiled, but require additional GIMPLE tree nodes.
> for (i =0; i < 100; i++) {
>foo (i);
> }
>
>
> As far as I know, for loops are lowered to jumps by C front-end and
> natural loops are detected later, so there is no strait way of passing
> such information.
> OpenMP pragmas provides such functionality, but require additional
> GIMPLE nodes to be defined and carried through all optimization
> passes,
> which I would prefer to avoid (if possible). So, is there any strait
> way to implement this?
A natural way would be to attach such information to the on-the side
loop structure tree (cfgloop.h, struct loop). Unfortunately it is build
quite late, so at the moment you'd have to use a combination of
GIMPLE nodes and later transitioning it to loop struct annotations.
There is, of course, no reason to not at some point in the future
let frontends populate the initial loop tree and keep that up-to-date.
Richard.
>
> Best regards,
> Alexey
[cxx-conversion] Weekly merge from trunk
I've committed rev 194091. It brings all the changes to trunk from last week. I will be doing weekly merges from trunk into the branch. To avoid unnecessary spam, I won't announce merges unless something interesting happens. Tested on x86_64. Diego.
Issue with c++11 header random.h
In the c++11 headers for the random number generation (random.h), the function "discard" for the linear_congruential has been implemented in a very inefficient manner. Many modern Monte Carlo codes require this function to work efficiently across large strides through the random number stream. A direct approach is available through the Boost headers and has been documented in the literature. I would request that this function be reimplemented before more users discover it on accident as they transition from the boost headers to the c++11 ones you provide. Thanks for listening and great job on a great toolset! Sincerely, Steve Nolen XCP-3 Los Alamos National Laboratory
Re: plans for 'Rvalue references for *this' support?
On 03/12/2012 03:09, Kenny Simpson wrote: From http://gcc.gnu.org/projects/cxx0x.html, I see that this seems to be the only major core-language feature missing from c++11 support. And from http://clang.llvm.org/cxx_status.html I see that clang does support it. I see the note saying that it was being worked on, but this note had been there for a while. Is it still planned/in-progress, deemed It is in progress. Mostly implemented, but the patch is held by employer disclaimer, at the moment. B.
Re: Issue with c++11 header random.h
On Mon, Dec 3, 2012 at 10:54 AM, Nolen, Steven D wrote: > In the c++11 headers for the random number generation (random.h), the > function "discard" for the linear_congruential has been implemented in a very > inefficient manner. Many modern Monte Carlo codes require this function to > work efficiently across large strides through the random number stream. A > direct approach is available through the Boost headers and has been > documented in the literature. I would request that this function be > reimplemented before more users discover it on accident as they transition > from the boost headers to the c++11 ones you provide. This probably should be opened as a libstdc++ enhancement request in GCC Bugzilla. Can LANL write and contribute a better implementation or contract someone to do so? Thanks, David
Re: Issue with c++11 header random.h
Hi, On 12/03/2012 04:54 PM, Nolen, Steven D wrote: In the c++11 headers for the random number generation (random.h), the function "discard" for the linear_congruential has been implemented in a very inefficient manner. As I mentioned when we optimized a while ago the discard member function for the statistically much more solid mersenne_twister engine, most of the discard are still just trivial implementations of the specs, that is rather well know. On the other hand, we didn't take code from Boost for our implementation and I don't think we are starting now. Thus, if you want to see progress on this specific discard, I would recommend either contributing a patch, if the issue is simple enough for you to handle, or filing an appropriate Bugzilla entry with a description of the optimization, then somebody will contribute an implementation. Thanks! Paolo.
RE: Failure to vectorize widen mult through intermediate steps
Is the lack of replies a sign that I missed to explain something in my email?
Cheers,
Paulo Matos
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Paulo
> Matos
> Sent: 29 November 2012 17:04
> To: gcc@gcc.gnu.org
> Subject: Failure to vectorize widen mult through intermediate steps
>
> Hello,
>
> I have been looking at a piece of code that fails to vectorize because
> GCC4.7.0 is unable in suportable_widening_operation to provide proper
> conversions for a WIDEN_MULT_EXPR. vectype_in is V8HI and vectype_out is
> V2DI. The problem seems to be that GCC code at the end of this functions
> blocks the search for intermediate conversions. If GCC would look for them it
> would find:
> vec_widen_smult_lo_v8hi with v4si output
> vec_widen_smult_lo_v4si with v2di output
> however, since this search doesn't occur, vectorization fails.
>
> How can I instruct GCC that it should take this steps to enable vectorization
> between these vectypes?
> I thought about defining vec_widen_smult_lo_v8hi with v2di output but can't
> because of the constraints on the pattern ("Multiply the high/low elements of
> the two vectors, and put the N/2 products of size 2*S in the output vector
> (operand 0).").
>
> The hook TARGET_VECTORIZE_BUILTIN_CONVERSION sounds like it could be what I
> want but I added some test code and in my simple example this function is
> never called.
>
> Any suggestions on how to work this out in the backend?
>
> Cheers,
>
> Paulo Matos
>
Re: Issue with c++11 header random.h
On 12/03/2012 11:29 AM, Paolo Carlini wrote: Hi, On 12/03/2012 04:54 PM, Nolen, Steven D wrote: In the c++11 headers for the random number generation (random.h), the function "discard" for the linear_congruential has been implemented in a very inefficient manner. As I mentioned when we optimized a while ago the discard member function for the statistically much more solid mersenne_twister engine, most of the discard are still just trivial implementations of the specs, that is rather well know. On the other hand, we didn't take code from Boost for our implementation and I don't think we are starting now. Thus, if you want to see progress on this specific discard, I would recommend either contributing a patch, if the issue is simple enough for you to handle, or filing an appropriate Bugzilla entry with a description of the optimization, then somebody will contribute an implementation. Thanks! Paolo. Greetings, Thank you for your concern about the random facility. A link to a reference paper or two would help if you don't want to/can't contribute a patch. Thanks, Ed
Re: Ways to add source annotations to a loop
On Mon, 2012-12-03 at 12:19 +0100, Richard Biener wrote:
> On Mon, Dec 3, 2012 at 11:05 AM, Alexey Kravets wrote:
> > Hello,
> > I am looking for a way to implement source annotation (or something
> > similar) for a for loops. Basically, I need some mechanism to mark
> > certain for loops in the source code for the GIMPLE optimization
> > passes (for C/C++ only currently).
> > For example something like this:
> >
> > int i;
> > __attribute__((marked)) // Not compilable by GCC.
> > for (i =0; i < 100; i++) {
> >foo (i);
> > }
> >
> > or
> >
> > int i;
> >
> > #pragma marked // Can be compiled, but require additional GIMPLE tree nodes.
> > for (i =0; i < 100; i++) {
> >foo (i);
> > }
> >
> >
> > As far as I know, for loops are lowered to jumps by C front-end and
> > natural loops are detected later, so there is no strait way of passing
> > such information.
> > OpenMP pragmas provides such functionality, but require additional
> > GIMPLE nodes to be defined and carried through all optimization
> > passes,
> > which I would prefer to avoid (if possible). So, is there any strait
> > way to implement this?
>
> A natural way would be to attach such information to the on-the side
> loop structure tree (cfgloop.h, struct loop). Unfortunately it is build
> quite late, so at the moment you'd have to use a combination of
> GIMPLE nodes and later transitioning it to loop struct annotations.
> There is, of course, no reason to not at some point in the future
> let frontends populate the initial loop tree and keep that up-to-date.
I don't know if this gives you what you need, but an approach that
occurred to me is to mark the iterator variable with a custom attribute:
int i __attribute__((iterator_for_one_of_the_interesting_loops));
for (i =0; i < 100; i++) {
foo (i);
}
Perhaps you could use that to detect the loops of interest: the
initialization, the comparison, and the increment?
Hope this is helpful
Dave
Re: Ways to add source annotations to a loop
Hello,
That looks interesting thanks for pointing that out.
On Mon, Dec 3, 2012 at 5:11 PM, David Malcolm wrote:
> On Mon, 2012-12-03 at 12:19 +0100, Richard Biener wrote:
>> On Mon, Dec 3, 2012 at 11:05 AM, Alexey Kravets wrote:
>> > Hello,
>> > I am looking for a way to implement source annotation (or something
>> > similar) for a for loops. Basically, I need some mechanism to mark
>> > certain for loops in the source code for the GIMPLE optimization
>> > passes (for C/C++ only currently).
>> > For example something like this:
>> >
>> > int i;
>> > __attribute__((marked)) // Not compilable by GCC.
>> > for (i =0; i < 100; i++) {
>> >foo (i);
>> > }
>> >
>> > or
>> >
>> > int i;
>> >
>> > #pragma marked // Can be compiled, but require additional GIMPLE tree
>> > nodes.
>> > for (i =0; i < 100; i++) {
>> >foo (i);
>> > }
>> >
>> >
>> > As far as I know, for loops are lowered to jumps by C front-end and
>> > natural loops are detected later, so there is no strait way of passing
>> > such information.
>> > OpenMP pragmas provides such functionality, but require additional
>> > GIMPLE nodes to be defined and carried through all optimization
>> > passes,
>> > which I would prefer to avoid (if possible). So, is there any strait
>> > way to implement this?
>>
>> A natural way would be to attach such information to the on-the side
>> loop structure tree (cfgloop.h, struct loop). Unfortunately it is build
>> quite late, so at the moment you'd have to use a combination of
>> GIMPLE nodes and later transitioning it to loop struct annotations.
>> There is, of course, no reason to not at some point in the future
>> let frontends populate the initial loop tree and keep that up-to-date.
>
> I don't know if this gives you what you need, but an approach that
> occurred to me is to mark the iterator variable with a custom attribute:
>
> int i __attribute__((iterator_for_one_of_the_interesting_loops));
> for (i =0; i < 100; i++) {
>foo (i);
> }
>
> Perhaps you could use that to detect the loops of interest: the
> initialization, the comparison, and the increment?
>
> Hope this is helpful
> Dave
>
