Re: Offloading GSOC 2015
Hi! On Tue, 3 Mar 2015 16:16:21 +0100, guray ozen wrote: > I finished my master at Barcelona Supercomputing Center and i started > to do PhD. My master thesis code generation OpenMP 4.0 for GPU > accelerators. And i am still working on it. > > Last year i presented my research compiler MACC at IWOMP'14 which is > based on OmpSs runtime (http://pm.bsc.es/). You can check here my > paper and related paper > http://portais.fieb.org.br/senai/iwomp2014/presentations/Guray_Ozen.pptx > http://link.springer.com/chapter/10.1007%2F978-3-319-11454-5_16 > > As far as i know, GCC 5 will come with OpenMP 4.0 and OpenACC > offloading. I am wondering that are there a any project related code > generation within gsoc 2015? Because when i checked todo list about > offloading, i couldn't come accross. or what am i supposed to do? The idea that you propose seems like a fine project for GSoC -- definitely there'll be enough work to be done. ;-) Somebody from the GCC side needs to step up as a mentor. Grüße, Thomas signature.asc Description: PGP signature
Re: Undefined behavior due to 6.5.16.1p3
Dear Joseph,
On 03/10/2015 11:01 PM, Joseph Myers wrote:
and did "u.b.b2 = f (u.a);" instead of "u.b.b2 = u.a;", that would not be
undefined (see 6.8.6.4 and GCC PR 43784).
Thanks for the references, those are useful!
But what about "long long" on 32 bits machines. For example:
union {
long long a;
struct { char b1; long long b2; } b;
} u;
Will GCC perform similar optimizations as for the case of big structs? I
tried to play around with long long in Martin's example, but failed to
trigger "unexpected" behaviors in GCC.
Robbert
Re: Undefined behavior due to 6.5.16.1p3
On 03/11/2015 07:27 AM, Robbert Krebbers wrote:
Dear Joseph,
On 03/10/2015 11:01 PM, Joseph Myers wrote:
and did "u.b.b2 = f (u.a);" instead of "u.b.b2 = u.a;", that would not be
undefined (see 6.8.6.4 and GCC PR 43784).
Thanks for the references, those are useful!
But what about "long long" on 32 bits machines. For example:
union {
long long a;
struct { char b1; long long b2; } b;
} u;
Will GCC perform similar optimizations as for the case of big structs? I
tried to play around with long long in Martin's example, but failed to
trigger "unexpected" behaviors in GCC.
Whether or not this will preserve the source value will depend
on the alignment of long long (32 or 64 bits) and on how gcc
decides to copy the contents of the operands.
Commonly 8-byte aligned long longs will not overlap in the union
above so the value will always be preserved.
When long long is aligned on a 4 byte boundary (as in the i386
ABI) the two long long members will overlap, but if the whole
source operand is read into a pair of registers first and only
then written out into the destination operand then the original
value will also be preserved.
Martin
Re: Undefined behavior due to 6.5.16.1p3
On 2015-03-11 14:27:25 +0100, Robbert Krebbers wrote:
> But what about "long long" on 32 bits machines. For example:
>
> union {
> long long a;
> struct { char b1; long long b2; } b;
> } u;
>
> Will GCC perform similar optimizations as for the case of big structs? I
> tried to play around with long long in Martin's example, but failed to
> trigger "unexpected" behaviors in GCC.
I've not tried, but how about something like:
struct S { long a, b, c, d; };
union U {
struct S a;
struct { char b1; struct S b2; } b;
};
u.b.b2 = u.a;
or: u.a = u.b.b2;
IMHO, struct S should be large enough to avoid using registers as
a temporary area (just in case...).
--
Vincent Lefèvre - Web:
Re: Undefined behavior due to 6.5.16.1p3
On 2015-03-11 17:11:55 +0100, Jakub Jelinek wrote:
> On Wed, Mar 11, 2015 at 05:08:16PM +0100, Vincent Lefevre wrote:
> > On 2015-03-11 14:27:25 +0100, Robbert Krebbers wrote:
> > > But what about "long long" on 32 bits machines. For example:
> > >
> > > union {
> > > long long a;
> > > struct { char b1; long long b2; } b;
> > > } u;
> > >
> > > Will GCC perform similar optimizations as for the case of big structs? I
> > > tried to play around with long long in Martin's example, but failed to
> > > trigger "unexpected" behaviors in GCC.
> >
> > I've not tried, but how about something like:
> >
> > struct S { long a, b, c, d; };
> > union U {
> > struct S a;
> > struct { char b1; struct S b2; } b;
> > };
> > u.b.b2 = u.a;
> >
> > or: u.a = u.b.b2;
> >
> > IMHO, struct S should be large enough to avoid using registers as
> > a temporary area (just in case...).
>
> There is some PR about it in our bugzilla, and the conclusion is that
> it is both invalid
I agree that this is invalid, but Robbert wanted such an example
of 6.5.16.1p3 showing that it was indeed undefined behavior.
> (in C only one union member can be active at any time,
> we as extension allow type punning through unions etc.)
I disagree that it is an extension. The standard does not say
that "one union member can be active at any time".
The interpretation under which this is allowed in confirmed by
Note 95 of 6.5.2.3p3.
> and we really don't want to support it.
--
Vincent Lefèvre - Web:
Re: Undefined behavior due to 6.5.16.1p3
On 11 March 2015 at 16:11, Jakub Jelinek wrote: > There is some PR about it in our bugzilla, and the conclusion is that > it is both invalid (in C only one union member can be active at any time, > we as extension allow type punning through unions etc.) > and we really don't want to support it. I thought type punning was valid since C99 (but not C89 or any version of C++).
Re: Undefined behavior due to 6.5.16.1p3
On Wed, Mar 11, 2015 at 05:31:01PM +0100, Vincent Lefevre wrote: > > (in C only one union member can be active at any time, > > we as extension allow type punning through unions etc.) > > I disagree that it is an extension. The standard does not say > that "one union member can be active at any time". That is not a standard wording, but what I meant is 6.2.6.1p7 - that when you store some union member other union members take unspecified values. Jakub
gcc-4.9-20150311 is now available
Snapshot gcc-4.9-20150311 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20150311/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch revision 221363 You'll find: gcc-4.9-20150311.tar.bz2 Complete GCC MD5=d0baff06922580db18c113252f286f5b SHA1=de207d08ed44c5274d72d569e422884c9af53284 Diffs from 4.9-20150304 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
inline asm clobbers
Why does gcc allow you to specify clobbers using numbers:
asm ("" : : "r" (var) : "0"); // i386: clobbers eax
How is this better than using register names?
This makes even less sense when you realize that (apparently) the
indices of registers aren't fixed. Which means there is no way to know
which register you have clobbered in order to use it in the template.
Having just seen someone trying (unsuccessfully) to use this, it seems
like there is no practical way you can.
Which makes me wonder why it's there. And whether it still should be.
dw
Re: Undefined behavior due to 6.5.16.1p3
On 03/11/2015 05:31 PM, Vincent Lefevre wrote:
I disagree that it is an extension. The standard does not say
that "one union member can be active at any time".
The interpretation under which this is allowed in confirmed by
Note 95 of 6.5.2.3p3.
Effective types disallow to access a union member other than the current
one arbitrarily, so naively effective types contradict note 95 of 6.5.2.3p3.
I think the GCC interpretation makes sense. See the following excerpt
from the "-fstrict-aliasing" description in the gcc man page:
Allow the compiler to assume the strictest aliasing rules applicable to the language being compiled. For C (and C++),
this activates optimizations based on the type of expressions. In particular, an object of one type is assumed never
to reside at the same address as an object of a different type, unless the types are almost the same. For example, an
"unsigned int" can alias an "int", but not a "void*" or a "double". A character
type may alias any other type.
Pay special attention to code like this:
union a_union {
int i;
double d;
};
int f() {
union a_union t;
t.d = 3.0;
return t.i;
}
The practice of reading from a different union member than the one most recently written
to (called "type-punning") is common. Even with -fstrict-aliasing,
type-punning is allowed, provided the memory is accessed through the union type. So, the
code above works as expected.However, this code might not:
int f() {
union a_union t;
int* ip;
t.d = 3.0;
ip = &t.i;
return *ip;
}
Similarly, access by taking the address, casting the resulting pointer and
dereferencing the result has undefined behavior, even if the cast uses a union
type, e.g.:
int f() {
double d = 3.0;
return ((union a_union *) &d)->i;
}
Re: inline asm clobbers
On Wed, Mar 11, 2015 at 3:58 PM, David Wohlferd wrote:
>
> Why does gcc allow you to specify clobbers using numbers:
>
>asm ("" : : "r" (var) : "0"); // i386: clobbers eax
>
> How is this better than using register names?
>
> This makes even less sense when you realize that (apparently) the indices of
> registers aren't fixed. Which means there is no way to know which register
> you have clobbered in order to use it in the template.
>
> Having just seen someone trying (unsuccessfully) to use this, it seems like
> there is no practical way you can.
>
> Which makes me wonder why it's there. And whether it still should be.
I don't know why it works. It should be consistent, though. It's
simply GCC's internal hard register number, which doesn't normally
change.
I would agree that one should avoid it. I'd be wary of removing it
from GCC at this point since it might break working code.
Ian
Re: inline asm clobbers
> On Mar 11, 2015, at 7:19 PM, Ian Lance Taylor wrote:
>
> On Wed, Mar 11, 2015 at 3:58 PM, David Wohlferd
> wrote:
>>
>> Why does gcc allow you to specify clobbers using numbers:
>>
>> asm ("" : : "r" (var) : "0"); // i386: clobbers eax
>>
>> How is this better than using register names?
>>
>> This makes even less sense when you realize that (apparently) the indices of
>> registers aren't fixed. Which means there is no way to know which register
>> you have clobbered in order to use it in the template.
>>
>> Having just seen someone trying (unsuccessfully) to use this, it seems like
>> there is no practical way you can.
>>
>> Which makes me wonder why it's there. And whether it still should be.
>
> I don't know why it works. It should be consistent, though. It's
> simply GCC's internal hard register number, which doesn't normally
> change.
>
> I would agree that one should avoid it. I'd be wary of removing it
> from GCC at this point since it might break working code.
It certainly would. It’s not all that common, but I have seen this done in
production code. Come to think of it, this certainly makes sense in machines
where some instructions act on fixed registers.
Register names would be nice as an additional capability.
paul
Re: inline asm clobbers
On Wed, Mar 11, 2015 at 4:41 PM, wrote:
>
>> On Mar 11, 2015, at 7:19 PM, Ian Lance Taylor wrote:
>>
>> On Wed, Mar 11, 2015 at 3:58 PM, David Wohlferd
>> wrote:
>>>
>>> Why does gcc allow you to specify clobbers using numbers:
>>>
>>> asm ("" : : "r" (var) : "0"); // i386: clobbers eax
>>>
>>> How is this better than using register names?
>>>
>>> This makes even less sense when you realize that (apparently) the indices of
>>> registers aren't fixed. Which means there is no way to know which register
>>> you have clobbered in order to use it in the template.
>>>
>>> Having just seen someone trying (unsuccessfully) to use this, it seems like
>>> there is no practical way you can.
>>>
>>> Which makes me wonder why it's there. And whether it still should be.
>>
>> I don't know why it works. It should be consistent, though. It's
>> simply GCC's internal hard register number, which doesn't normally
>> change.
>>
>> I would agree that one should avoid it. I'd be wary of removing it
>> from GCC at this point since it might break working code.
>
> It certainly would. It’s not all that common, but I have seen this done in
> production code. Come to think of it, this certainly makes sense in machines
> where some instructions act on fixed registers.
>
> Register names would be nice as an additional capability.
Register names are supported.
Ian
Re: inline asm clobbers
On 3/11/2015 4:19 PM, Ian Lance Taylor wrote:
On Wed, Mar 11, 2015 at 3:58 PM, David Wohlferd wrote:
Why does gcc allow you to specify clobbers using numbers:
asm ("" : : "r" (var) : "0"); // i386: clobbers eax
How is this better than using register names?
This makes even less sense when you realize that (apparently) the indices of
registers aren't fixed. Which means there is no way to know which register
you have clobbered in order to use it in the template.
Having just seen someone trying (unsuccessfully) to use this, it seems like
there is no practical way you can.
Which makes me wonder why it's there. And whether it still should be.
I don't know why it works. It should be consistent, though. It's
simply GCC's internal hard register number, which doesn't normally
change.
The reason I believe the order can change is this comment from i386.h:
/* Order in which to allocate registers. Each register must be
listed once, even those in FIXED_REGISTERS. List frame pointer
late and fixed registers last. Note that, in general, we prefer
registers listed in CALL_USED_REGISTERS, keeping the others
available for storage of persistent values.
The ADJUST_REG_ALLOC_ORDER actually overwrite the order,
so this is just empty initializer for array. */
My attempts to follow ADJUST_REG_ALLOC_ORDER were not particularly
successful, but it did take me to this comment in ira.c:
/* This is called every time when register related information is
changed. */
I would agree that one should avoid it. I'd be wary of removing it
from GCC at this point since it might break working code.
I hear you on this. Removing existing functionality is definitely
risky, so I agree with your caution. And of course changing anything is
much less important if the register order here really is fixed.
On the other hand, what if my fear about register order changing is
correct? In that case people who assume (as you have) that they don't
change are clobbering random registers. Also, the fellow I saw trying
to use this (incorrectly) assumed that "0" was referring to the same
thing as the template's "%0."
If people don't (or if in fact it is impossible to) use this safely,
"breaking" their code by forcing them to use register names might be the
best way to fix it.
dw
Re: inline asm clobbers
On 3/11/2015 4:41 PM, paul_kon...@dell.com wrote:
On Mar 11, 2015, at 7:19 PM, Ian Lance Taylor wrote:
On Wed, Mar 11, 2015 at 3:58 PM, David Wohlferd wrote:
Why does gcc allow you to specify clobbers using numbers:
asm ("" : : "r" (var) : "0"); // i386: clobbers eax
How is this better than using register names?
This makes even less sense when you realize that (apparently) the indices of
registers aren't fixed. Which means there is no way to know which register
you have clobbered in order to use it in the template.
Having just seen someone trying (unsuccessfully) to use this, it seems like
there is no practical way you can.
Which makes me wonder why it's there. And whether it still should be.
I don't know why it works. It should be consistent, though. It's
simply GCC's internal hard register number, which doesn't normally
change.
I would agree that one should avoid it. I'd be wary of removing it
from GCC at this point since it might break working code.
It certainly would. It’s not all that common, but I have seen this done in
production code. Come to think of it, this certainly makes sense in machines
where some instructions act on fixed registers.
Really? While I've seen much code that uses clobbers, I have never
(until this week) see anyone attempt to clobber by index. Since I'm
basically an i386 guy, maybe this is a platform thing? Do you have some
examples/links?
Register names would be nice as an additional capability.
Every example I've ever seen uses register names. Perhaps that what
you've seen before?
dw
Re: Undefined behavior due to 6.5.16.1p3
On Wed, 11 Mar 2015, Vincent Lefevre wrote:
> BTW, the following is forbidden (and makes no sense), but is accepted
> by GCC without a warning:
>
> int foo (void)
> {
> union { char a[8]; int b; } u = { .a = { 0 }, .b = 1 };
> return u.b;
> }
What constraint do you think forbids it? It looks like an ordinary case
of overriding with designated initializers.
--
Joseph S. Myers
jos...@codesourcery.com
Re: inline asm clobbers
On Wed, Mar 11, 2015 at 5:51 PM, David Wohlferd wrote: > > The reason I believe the order can change is this comment from i386.h: > > /* Order in which to allocate registers. Each register must be >listed once, even those in FIXED_REGISTERS. List frame pointer >late and fixed registers last. Note that, in general, we prefer >registers listed in CALL_USED_REGISTERS, keeping the others >available for storage of persistent values. > >The ADJUST_REG_ALLOC_ORDER actually overwrite the order, >so this is just empty initializer for array. */ That is REG_ALLOC_ORDER. The index that appears in an asm statement is the hard register number. REG_ALLOC_ORDER is an array holding hard register numbers. The hard register numbers can change in principle, by changing the source code, but I actually can't recall that ever happening. Ian
