Re: [RFC] Target compilation for offloading
Ping On Fri, Nov 15, 2013 at 7:45 PM, Andrey Turetskiy wrote: > Let's suppose, we are going to run target gcc driver from lto-wrapper. > How could a list of offload targets be passed there from option > parser? > In my opinion, the simpliest way to do it is to use environment > variable. Would you agree with such approach? > > On Fri, Nov 8, 2013 at 6:34 PM, Jakub Jelinek wrote: >> On Fri, Nov 08, 2013 at 06:26:53PM +0400, Andrey Turetskiy wrote: >>> Thanks. >>> And a few questions about compiler options: >>> 1) You've mentioned two options for offloading: >>> -foffload-target= - to specify targets for offloading >>> -foffload-target-= - to specify >>> compiler options for different targets >>> Do we really need two options to set up offloading? >>> What do you think about, in my opinion, more compact way: >>> -foffload- - if I want to offload for 'target name', >>> but I don't want to specify any options >>> -foffload-= - enable offloading for >>> 'target name' and set options >>> And compilation for several targets would look like: >>> gcc -fopenmp -foffload-mic="-O3 -msse -m64" -foffload-ptx >>> -foffload-hsail="-O2 -m32" file.c >> >> I don't think it is a good idea to include the target name before = >> in the name of the option, but perhaps you can use two =s: >> -foffloat-target=x86_64-k1om-linux="-O2 -mtune=foobar' >> -foffloat-target=ptx-none >> >>> 2) If user doesn't specify target options directly, is target >>> compilation done without any option or compiler uses those host >>> options which are suitable for target? >> >> I think I've said that earlier, non-target specific options from original >> compilation should be copied over, target specific options discarded, >> and the command line supplied overrides appended to that. >> >>> 3) Am I understand right, that options for different targets should be >>> stored in different sections in fat object file, and than lto frontend >>> should read theese options and run target compilation with them? >> >> No, I'd store in the LTO target IL only the original host compilation >> options that weren't target specific (opt* has some flags what is target >> specific and what is not), so say -O2 -ftree-vrp would go there, >> but say -march=corei7-avx would not. And the -foffload-target= options >> would only matter during linking. >> >> Jakub > > > > -- > Best regards, > Andrey Turetskiy -- Best regards, Andrey Turetskiy
how to use -fomit-frame-pointer by default
Hi, I'm migrating my private port from gcc 4.5.2 to gcc 4.7.3. I noticed that -fomit-frame-pointer was not triggered when using -O1 -O2 or -O3. Could you indicate me how to modify my port to use -fomit-frame-pointer by default (as it was in gcc 4.5.2 I presume) ? Regards, Selim
Re: memset zero bytes at NULL - isolate-erroneous-paths
On Mon, Nov 18, 2013 at 3:24 PM, Jeff Law wrote:
> On 11/18/13 04:08, Richard Biener wrote:
>>>
>>> I'd say that turning memset (0, '\0', 0) into a trap is bad from a QOI
>>
>> perspective. Jeff, is there an easy way to avoid this? Testcase:
>>
>> void fn (void *addr, int a)
>> {
>>if (a == 0)
>> addr = (void *)0;
>>__builtin_memset (addr, '\0', a);
>> }
>>
>> I wonder where in isolate-paths you check for builtins at all? ah,
>> it's probably from the nonnull attribute on memset. Which also
>> means that trying to catch this case reliably isn't going to work
>> (you cannot prove the program has len == 0 in this case and
>> conditionally not trapping would somewhat defeat the purpose
>> of isolating this path)
>
> It's the nonnull attribute on memset. One thought would split the
> optimization into two parts. One which transforms *0 and the other which
> transforms calls/returns. Have the former enabled by -O2 the latter off for
> now. For the next release, both enabled by default at -O2.
>
> Add distinct warnings for both cases, possibly enabled by -Wall (depends on
> the noise).
>
> That gets most of the benefit now and gives a way for users to identify
> brokenness in their code.
>
> Sadly, this feels a lot like -fstrict-aliasing did eons ago. Aggressive
> TBAA exposed all kinds problems and it took a lot of user (re)education to
> get them fixed.
Yeah ... splitting the flag may help tracking down bogus nonnull attributes
as well (we're still seeing invalid uses of the malloc attribute ...).
Richard.
> jeff
RE: OpenACC or OpenMP 4.0 target directives
> I came across a news about gcc will support OpenACC/OpenMP target > directive. How can i download this version? There some action should be done to get sources: git clone git://gcc.gnu.org/git/gcc.git cd gcc git config --add remote.origin.fetch refs/remotes/openacc-1_0-branch:refs/remotes/origin/openacc-1_0-branch git config --add remote.origin.fetch refs/remotes/GOMP-4_0-branch:refs/remotes/origin/GOMP-4_0-branch git fetch git pull Then checkout openacc or gomp branch. And be in sync with this guide: http://gcc.gnu.org/wiki/GitMirror Also, check this thread http://gcc.gnu.org/ml/gcc/2013-09/msg00235.html for extra tips on how to build openacc-1_0-branch. Thanks to Tobias for mentioning OpenCL examples: http://gcc.gnu.org/ml/gcc/2013-10/msg9.html My colleague, Ilmir, prepared them to show, how OpenACC can be represented in OpenCL. This is just WIP document, so it may have some issues in there. Nevertheless, it can be interesting to you. In case, you'll have some questions related to OpenACC - feel free to ask it on mailing list. Regarding books and articles and etc. Much depends on your, but I'd definitely recommend this book: Optimizing Compilers for Modern Architectures by Allen & Kennedy. Also, check this ancient article: http://www.cs.utexas.edu/users/mckinley/papers/95-59-1995.pdf It contains many references and buzzwords that may help you to start your research. - Thanks, Evgeny.
Running contrib/config-list.mk from the buildbots
I've been thinking that it would be very useful for buildbots to run contrib/config-list.mk. This tests stage1's all-gcc on a very wide collection of targets. It builds everything with -Werror, so it requires a recent host compiler (ideally trunk or the latest release). Currently, many targets are broken because of -Werror. I was thinking of fixing them, but unless we keep them clean with a buildbot they will regress. Would this be hard to set up in your buildbots? Thanks. Diego.
Re: Running contrib/config-list.mk from the buildbots
On 2013-11-19 16:20, Diego Novillo wrote: I've been thinking that it would be very useful for buildbots to run contrib/config-list.mk. This tests stage1's all-gcc on a very wide collection of targets. It builds everything with -Werror, so it requires a recent host compiler (ideally trunk or the latest release). What requirements must a target fulfill to get on this list? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: Running contrib/config-list.mk from the buildbots
On Tue, Nov 19, 2013 at 10:29 AM, Sebastian Huber wrote: > On 2013-11-19 16:20, Diego Novillo wrote: >> >> I've been thinking that it would be very useful for buildbots to run >> contrib/config-list.mk. This tests stage1's all-gcc on a very wide >> collection of targets. It builds everything with -Werror, so it >> requires a recent host compiler (ideally trunk or the latest release). > > > What requirements must a target fulfill to get on this list? It has to be actively maintained, of course. The first test is to see if the target builds with contrib/config-list.mk (with -Werror disabled). If it does, and Jan-Benedict can add the script to a buildbot, then you're all set. You just need to send a patch to change config-list.mk. Diego.
Re: Running contrib/config-list.mk from the buildbots
On Tue, Nov 19, 2013 at 4:20 PM, Diego Novillo wrote: > Currently, many targets are broken because of -Werror. I was thinking > of fixing them, but unless we keep them clean with a buildbot they > will regress. How nobel. But isn't this what we have port maintainers for? I'd say: Let it be! If a port is actively maintained, any breakage will be found quickly. The amount of Werror breakage is a good KPI for the maintenance state of a port :-) It's all accidental breakage, and there's no obligation to test patches on all targets. Ciao! Steven
Re: Running contrib/config-list.mk from the buildbots
Hi Diego! On Tue, 2013-11-19 10:20:48 -0500, Diego Novillo wrote: > I've been thinking that it would be very useful for buildbots to run > contrib/config-list.mk. This tests stage1's all-gcc on a very wide > collection of targets. It builds everything with -Werror, so it > requires a recent host compiler (ideally trunk or the latest release). > > Currently, many targets are broken because of -Werror. I was thinking > of fixing them, but unless we keep them clean with a buildbot they > will regress. > > Would this be hard to set up in your buildbots? I haven't ever directly used config-list.mk, so I'm just guessing around here :) Starting from making it work, different host-local options may need to be set (cf. "host_options='--with-mpc=/opt/cfarm/mpc' # gcc10" found in that file.) Additional to that, it needs a combined tree, right? Shouldn't be much of a problem. With Ada and Go (as well as `all' languages), there are quite a few more dependencies, so I guess I wouldn't like to run it on all hosts. Since it builds (per default) all targets, it'll have a *hugh* runtime (if not run in parallel.) That is, I would NOT consider running it as-is on the hosts. However, since I need to touch the scheduler due to other reasons, I'm thinking about parsing config-list.mk's host list and schedule individual builds on (picked) build slaves. That would additionally have the advantage of having single builds showing up in the web frontend, and not one hugh long-running job where you can then have a look at the individual logs (per target.) Final notes: It needs a small change in the script running on the target, as well as a change to the scheduler, to make it "work". Maybe it would be worthwile to not mix my current results with those of config-list.mk, since they build/test different things. But that's, too, just a flag in a database table. So I think I'll just have a look in-detail at it and prepare a test on one of the cfarm machines. Since config-list.mk builds quite more than I do right now, it would be a hugh win to go into that direction. Thanks for the idea :) MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: Alles wird gut! ...und heute wirds schon ein bißchen besser. the second : signature.asc Description: Digital signature
Re: Running contrib/config-list.mk from the buildbots
On Tue, Nov 19, 2013 at 12:03 PM, Jan-Benedict Glaw wrote: > Hi Diego! > > On Tue, 2013-11-19 10:20:48 -0500, Diego Novillo wrote: >> I've been thinking that it would be very useful for buildbots to run >> contrib/config-list.mk. This tests stage1's all-gcc on a very wide >> collection of targets. It builds everything with -Werror, so it >> requires a recent host compiler (ideally trunk or the latest release). >> >> Currently, many targets are broken because of -Werror. I was thinking >> of fixing them, but unless we keep them clean with a buildbot they >> will regress. >> >> Would this be hard to set up in your buildbots? > > I haven't ever directly used config-list.mk, so I'm just guessing > around here :) > > Starting from making it work, different host-local options may need > to be set (cf. "host_options='--with-mpc=/opt/cfarm/mpc' # gcc10" > found in that file.) Well, you need that for your other builds anyway, right? Everything needs a working gmp/mpfr/mpc. Anything that is optional does not need to be done with this script. > Additional to that, it needs a combined tree, right? Shouldn't be > much of a problem. No. It just needs a relatively recent set of tools on the host (gcc, binutils, etc) > With Ada and Go (as well as `all' languages), there are quite a few > more dependencies, so I guess I wouldn't like to run it on all hosts. We don't need to test Ada and Go with the buildbots. Really, the only thing interesting about the script is the broad set of targets it uses. If you just added them to the schedule of builds, that should be sufficient. We could even decide not to add all of them. And certainly take out the ones that just don't build as-is. Diego.
Re: Running contrib/config-list.mk from the buildbots
On Tue, 2013-11-19 12:08:05 -0500, Diego Novillo wrote: > On Tue, Nov 19, 2013 at 12:03 PM, Jan-Benedict Glaw wrote: > > On Tue, 2013-11-19 10:20:48 -0500, Diego Novillo > > wrote: [config-list.mk] > >> Would this be hard to set up in your buildbots? > > > > I haven't ever directly used config-list.mk, so I'm just guessing > > around here :) > > > > Starting from making it work, different host-local options may need > > to be set (cf. "host_options='--with-mpc=/opt/cfarm/mpc' # gcc10" > > found in that file.) > > Well, you need that for your other builds anyway, right? Everything > needs a working gmp/mpfr/mpc. Anything that is optional does not need > to be done with this script. That may be in different places. For the cfarm machines, that location is quite stable, but that doesn't make it globally correct. > > Additional to that, it needs a combined tree, right? Shouldn't be > > much of a problem. > > No. It just needs a relatively recent set of tools on the host (gcc, > binutils, etc) Ah, it's just building GCC itself, without binutils and eg. libgcc etc. Just didn't really notice. > > With Ada and Go (as well as `all' languages), there are quite a few > > more dependencies, so I guess I wouldn't like to run it on all hosts. > > We don't need to test Ada and Go with the buildbots. ...but I think it would be quite fun to do! > Really, the only thing interesting about the script is the broad set > of targets it uses. If you just added them to the schedule of builds, > that should be sufficient. We could even decide not to add all of > them. And certainly take out the ones that just don't build as-is. When I made that target list used in Build Robot, I actually took quite a few from config-list.mk . However, I usually stripped off all the ABI variants, leaving -linux or -elf for most of them. So really, I think this is a good idea to work on. Though due to -Werror, there'll be some fun stuff (aarch64-elf here, but all others will probably equally affected: g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace -DCLOOG_INT_GMP-o langhooks.o -MT langhooks.o -MMD -MP -MF ./.deps/langhooks.TPo ../../../gcc/gcc/langhooks.c ../../../gcc/gcc/langhooks.c: In function ‘void lhd_print_error_function(diagnostic_context*, const char*, diagnostic_info*)’: ../../../gcc/gcc/langhooks.c:460:41: error: unknown conversion type character ‘r’ in format [-Werror=format=] "locus", s.file, s.line, s.column); ^ ../../../gcc/gcc/langhooks.c:460:41: error: format ‘%d’ expects argument of type ‘int’, but argument 5 has type ‘const char*’ [-Werror=format=] ../../../gcc/gcc/langhooks.c:460:41: error: unknown conversion type character ‘R’ in format [-Werror=format=] ../../../gcc/gcc/langhooks.c:460:41: error: too many arguments for format [-Werror=format-extra-args] ../../../gcc/gcc/langhooks.c:465:31: error: unknown conversion type character ‘r’ in format [-Werror=format=] "locus", s.file, s.line); ^ ../../../gcc/gcc/langhooks.c:465:31: error: format ‘%d’ expects argument of type ‘int’, but argument 5 has type ‘const char*’ [-Werror=format=] ../../../gcc/gcc/langhooks.c:465:31: error: unknown conversion type character ‘R’ in format [-Werror=format=] ../../../gcc/gcc/langhooks.c:465:31: error: too many arguments for format [-Werror=format-extra-args] cc1plus: all warnings being treated as errors make[2]: *** [langhooks.o] Error 1 $ g++ --version g++ (Debian 4.8.1-7) 4.8.1 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: http://perl.plover.com/Questions.html the second : signature.asc Description: Digital signature
Re: Running contrib/config-list.mk from the buildbots
On Tue, 2013-11-19 12:08:05 -0500, Diego Novillo wrote:
[conffig-list.mk]
> Really, the only thing interesting about the script is the broad set
> of targets it uses. If you just added them to the schedule of builds,
> that should be sufficient. We could even decide not to add all of
> them. And certainly take out the ones that just don't build as-is.
With -Werror in place, I think not a single target will build right now, due to
warnings/errors in common code. Just picking a recent s390x-linux as an
example:
buildrobot@toolchaintest-host:~/xx$ wget -O s390x-linux.buildlog --quiet
'http://toolchain.lug-owl.de/buildbot/deliver_artifact.php?mode=download&id=252870'
buildrobot@toolchaintest-host:~/xx$ grep 'warning: ' s390x-linux.buildlog |wc -l
116
buildrobot@toolchaintest-host:~/xx$ grep 'warning: ' s390x-linux.buildlog |cut
-f 4- -d ':'|sort|uniq -c
3 operand 2 missing mode?
1 remember to run `libtool --finish
/home/jbglaw/build/s390x-linux/_install_/libexec/gcc/s390x-linux/4.9.0'
7 source missing a mode?
4 warning: dereferencing type-punned pointer will break strict-aliasing
rules [-Wstrict-aliasing]
11 warning: format '%d' expects argument of type 'int', but argument 4
has type 'const char*' [-Wformat=]
8 warning: format '%d' expects argument of type 'int', but argument 5
has type 'const char*' [-Wformat=]
2 warning: format '%s' expects argument of type 'char*', but argument 5
has type 'int' [-Wformat=]
3 warning: format '%s' expects argument of type 'char*', but argument 6
has type 'int' [-Wformat=]
18 warning: missing sentinel in function call [-Wformat=]
20 warning: too many arguments for format [-Wformat-extra-args]
19 warning: unknown conversion type character 'r' in format [-Wformat=]
19 warning: unknown conversion type character 'R' in format [-Wformat=]
1 warning: unknown conversion type character 'X' in format [-Wformat=]
Some of those are probably spurious and won't break the build, but all
of the -Wformat diagnostics will:
buildrobot@toolchaintest-host:~/xx$ grep "too many arguments for format"
s390x-linux.buildlog |cut -f 1 -d ':'|sort|uniq -c
8 /home/jbglaw/repos/gcc/gcc/cp/error.c
1 /home/jbglaw/repos/gcc/gcc/cp/method.c
3 /home/jbglaw/repos/gcc/gcc/diagnostic.c
2 /home/jbglaw/repos/gcc/gcc/langhooks.c
6 /home/jbglaw/repos/gcc/gcc/tree.c
I don't understand the "missing sentinel" messages; they're on code like this:
g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H
-DGENERATOR_FILE -I. -Ibuild -I/home/jbglaw/repos/gcc/gcc
-I/home/jbglaw/repos/gcc/gcc/build -I/home/jbglaw/repos/gcc/gcc/../include
-I/home/jbglaw/repos/gcc/gcc/../libcpp/include -I/opt/cfarm/gmp-latest/include
-I/opt/cfarm/mpfr-latest/include -I/opt/cfarm/mpc-latest/include
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber
-I/home/jbglaw/repos/gcc/gcc/../libbacktrace\
-o build/read-md.o /home/jbglaw/repos/gcc/gcc/read-md.c
/home/jbglaw/repos/gcc/gcc/read-md.c: In function 'const char*
join_c_conditions(const char*, const char*)':
/home/jbglaw/repos/gcc/gcc/read-md.c:203:58: warning: missing sentinel in
function call [-Wformat=]
result = concat ("(", cond1, ") && (", cond2, ")", NULL);
^
Maybe "NULL" isn't of pointer type and thus it would need a cast here...
MfG, JBG
--
Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481
Signature of:Lauf nicht vor Deinem Glück davon:
the second : Es könnte hinter Dir stehen!
signature.asc
Description: Digital signature
Re: Running contrib/config-list.mk from the buildbots
On Tue, Nov 19, 2013 at 1:11 PM, Jan-Benedict Glaw wrote: > On Tue, 2013-11-19 12:08:05 -0500, Diego Novillo wrote: > [conffig-list.mk] >> Really, the only thing interesting about the script is the broad set >> of targets it uses. If you just added them to the schedule of builds, >> that should be sufficient. We could even decide not to add all of >> them. And certainly take out the ones that just don't build as-is. > > With -Werror in place, I think not a single target will build right now, due > to > warnings/errors in common code. Just picking a recent s390x-linux as an > example: Right, because you're using 4.8. These warnings disappear when using trunk and/or do not actually break the build. I suppose this is too much for the buildbot then? It won't have a recent trunk around, so perhaps restricting it to the targets that actually build with 4.8 is the way to go. Diego.
Re: Running contrib/config-list.mk from the buildbots
On Tue, 2013-11-19 13:20:41 -0500, Diego Novillo wrote: > On Tue, Nov 19, 2013 at 1:11 PM, Jan-Benedict Glaw wrote: > > On Tue, 2013-11-19 12:08:05 -0500, Diego Novillo > > wrote: > > [conffig-list.mk] > >> Really, the only thing interesting about the script is the broad set > >> of targets it uses. If you just added them to the schedule of builds, > >> that should be sufficient. We could even decide not to add all of > >> them. And certainly take out the ones that just don't build as-is. > > > > With -Werror in place, I think not a single target will build right now, > > due to > > warnings/errors in common code. Just picking a recent s390x-linux as an > > example: > > Right, because you're using 4.8. These warnings disappear when using > trunk and/or do not actually break the build. I suppose this is too > much for the buildbot then? It won't have a recent trunk around, so > perhaps restricting it to the targets that actually build with 4.8 is > the way to go. The Build Robot just uses whatever GCC is there, if no compiler is set explicitely. (I tried that with eg. IBM's XL compiler, but that broke horribly. Still lots of stuff to clean up.) In general, building with a trunk (or otherwise recent) GCC isn't much of a problam if there's one around. MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: Gib Dein Bestes. Dann übertriff Dich selbst! the second : signature.asc Description: Digital signature
Re: Running contrib/config-list.mk from the buildbots
On 19 November 2013 18:20, Diego Novillo wrote: > Right, because you're using 4.8. These warnings disappear when using > trunk and/or do not actually break the build. I suppose this is too > much for the buildbot then? It won't have a recent trunk around, so > perhaps restricting it to the targets that actually build with 4.8 is > the way to go. No, that will likely get you the empty set. The most repeatable results are obtained by using the source tree under test to bootstrap a native compiler on the host first. If you use one massive host to run all of config-list.mk, that extra preparation generally doesn't make all that much difference (unless you happen to have a host with # of cores similar to # of test targets). If you run these tests on a host that also occaisonally does native bootstrap tests, you could extend that script to specify a --prefix and install the compiler if it's good.
Re: Running contrib/config-list.mk from the buildbots
On Tue, Nov 19, 2013 at 3:36 PM, Joern Rennecke wrote: > On 19 November 2013 18:20, Diego Novillo wrote: > >> Right, because you're using 4.8. These warnings disappear when using >> trunk and/or do not actually break the build. I suppose this is too >> much for the buildbot then? It won't have a recent trunk around, so >> perhaps restricting it to the targets that actually build with 4.8 is >> the way to go. > > No, that will likely get you the empty set. > The most repeatable results are obtained by using the source tree under test > to bootstrap a native compiler on the host first. If you use one massive host > to run all of config-list.mk, that extra preparation generally doesn't make > all that much difference (unless you happen to have a host with # of cores > similar to # of test targets). > > If you run these tests on a host that also occaisonally does native bootstrap > tests, you could extend that script to specify a --prefix and install > the compiler > if it's good. Even when using the same compiler you just built, there are targets that do not build cleanly with -Werror. I proposed cleaning them up. Steven suggested that we take them out of config-list.mk. Either works with me. Diego.
Multiple local register variables w/ same register
On 11/20/2013 03:33 AM, Peter Zijlstra wrote:
> On Tue, Nov 19, 2013 at 05:02:20PM +, Mathieu Desnoyers wrote:
>> Unfortunately I don't have a ARM cross-compiler setup ready. Nathan could
>> test
>> it for us though.
>>
>> It might shuffle things around enough to work around the issue, but with the
>> approach you propose, I would be concerned about the compiler being within
>> its rights to reorder the code into the following sequence:
>>
>> struct thread_info *ptra, *ptrb;
>>
>> ptra = current_thread_info();
>> /*
>> * each current_thread_info() would have a clobber on *sp, which orders
>> * those two wrt each other.
>> */
>> ptrb = current_thread_info();
>>
>> load from ptra->preempt_count;
>> /*
>> * however, the following accesses that depend on ptra and ptrb could be
>> * reordered if the compiler has no way to know that ptra and ptrb are
>> * aliased.
>> */
>> store to ptrb->preempt_count;
>>
>> One question that might be worth asking: with the local register variable
>> extension
>> (http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Local-Reg-Vars.html#Local-Reg-Vars)
>> (thanks to Jakub for the pointer), should the compiler consider two variables
>> bound to the same register as being aliased or not ? AFAIU, local reg vars
>> appear
>> to be architecture-specific, so maybe there is something fishy on ARM ?
It appears not:
int __attribute__((noinline)) f(void)
{
{
register int x __asm__("eax");
x = 1;
}
{
register int y __asm__("eax");
return ++y;
}
}
extern void abort(void);
int main(void)
{
if (f() != 2)
abort();
return 0;
}
Anyone see anything wrong with the testcase? Do we thing this sort of thing
ought to work, perhaps with scopes lengthened?
r~
Re: Multiple local register variables w/ same register
On Wed, Nov 20, 2013 at 07:56:57AM +1000, Richard Henderson wrote:
> It appears not:
>
> int __attribute__((noinline)) f(void)
> {
> {
> register int x __asm__("eax");
> x = 1;
> }
> {
> register int y __asm__("eax");
> return ++y;
> }
> }
>
> extern void abort(void);
>
> int main(void)
> {
> if (f() != 2)
> abort();
> return 0;
> }
>
> Anyone see anything wrong with the testcase? Do we thing this sort of thing
> ought to work, perhaps with scopes lengthened?
I'd say this is undefined, when a local register var goes out of scope,
it's value can change arbitrarily. If you insert some call in between the
two scopes, it will surely have clobbered value, and even if there isn't
any call in between those, any insn could in theory clobber those.
Jakub
Re: Multiple local register variables w/ same register
Richard Henderson writes:
> On 11/20/2013 03:33 AM, Peter Zijlstra wrote:
>> On Tue, Nov 19, 2013 at 05:02:20PM +, Mathieu Desnoyers wrote:
>>> Unfortunately I don't have a ARM cross-compiler setup ready. Nathan
>>> could test it for us though.
>>>
>>> It might shuffle things around enough to work around the issue, but
>>> with the approach you propose, I would be concerned about the
>>> compiler being within its rights to reorder the code into the
>>> following sequence:
>>>
>>> struct thread_info *ptra, *ptrb;
>>>
>>> ptra = current_thread_info();
>>> /*
>>> * each current_thread_info() would have a clobber on *sp, which orders
>>> * those two wrt each other.
>>> */
>>> ptrb = current_thread_info();
>>>
>>> load from ptra->preempt_count;
>>> /*
>>> * however, the following accesses that depend on ptra and ptrb could be
>>> * reordered if the compiler has no way to know that ptra and ptrb are
>>> * aliased.
>>> */
>>> store to ptrb->preempt_count;
>>>
>>> One question that might be worth asking: with the local register variable
>>> extension
>>> (http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Local-Reg-Vars.html#Local-Reg-Vars)
>>> (thanks to Jakub for the pointer), should the compiler consider two
>>> variables bound to the same register as being aliased or not ?
>>> AFAIU, local reg vars appear to be architecture-specific, so maybe
>>> there is something fishy on ARM ?
>
> It appears not:
>
> int __attribute__((noinline)) f(void)
> {
> {
> register int x __asm__("eax");
> x = 1;
> }
> {
> register int y __asm__("eax");
> return ++y;
> }
> }
>
> extern void abort(void);
>
> int main(void)
> {
> if (f() != 2)
> abort();
> return 0;
> }
>
> Anyone see anything wrong with the testcase? Do we thing this sort of
> thing ought to work, perhaps with scopes lengthened?
In general, I see no reason why the compiler should be forced to
preserve a register between blocks like that. Relying on a value
magically appearing in a general-purpose register seems to me fragile at
best. Code like this adds inter-block dependencies that would not
normally be there, and I'd rather not gamble on how the various
optimisation passes deal with it, if it is even noticed at all.
What happens if you some code clobbering eax (e.g. a function call)
between those two blocks? What do you think should happen?
--
Måns Rullgård
m...@mansr.com
Re: Multiple local register variables w/ same register
- Original Message -
> From: "Richard Henderson"
> To: "Peter Zijlstra" , "Mathieu Desnoyers"
>
> Cc: "Will Deacon" , linux-ker...@vger.kernel.org,
> "Catalin Marinas" ,
> lttng-...@lists.lttng.org, "Nathan Lynch" , "Paul E.
> McKenney"
> , "Linus Torvalds"
> , "Andrew Morton"
> , "Jakub Jelinek" ,
> gcc@gcc.gnu.org
> Sent: Tuesday, November 19, 2013 4:56:57 PM
> Subject: Multiple local register variables w/ same register
>
> On 11/20/2013 03:33 AM, Peter Zijlstra wrote:
> > On Tue, Nov 19, 2013 at 05:02:20PM +, Mathieu Desnoyers wrote:
> >> Unfortunately I don't have a ARM cross-compiler setup ready. Nathan could
> >> test
> >> it for us though.
> >>
> >> It might shuffle things around enough to work around the issue, but with
> >> the
> >> approach you propose, I would be concerned about the compiler being within
> >> its rights to reorder the code into the following sequence:
> >>
> >> struct thread_info *ptra, *ptrb;
> >>
> >> ptra = current_thread_info();
> >> /*
> >> * each current_thread_info() would have a clobber on *sp, which orders
> >> * those two wrt each other.
> >> */
> >> ptrb = current_thread_info();
> >>
> >> load from ptra->preempt_count;
> >> /*
> >> * however, the following accesses that depend on ptra and ptrb could be
> >> * reordered if the compiler has no way to know that ptra and ptrb are
> >> * aliased.
> >> */
> >> store to ptrb->preempt_count;
> >>
> >> One question that might be worth asking: with the local register variable
> >> extension
> >> (http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Local-Reg-Vars.html#Local-Reg-Vars)
> >> (thanks to Jakub for the pointer), should the compiler consider two
> >> variables
> >> bound to the same register as being aliased or not ? AFAIU, local reg vars
> >> appear
> >> to be architecture-specific, so maybe there is something fishy on ARM ?
>
> It appears not:
>
> int __attribute__((noinline)) f(void)
> {
> {
> register int x __asm__("eax");
> x = 1;
> }
> {
> register int y __asm__("eax");
> return ++y;
> }
> }
>
> extern void abort(void);
>
> int main(void)
> {
> if (f() != 2)
> abort();
> return 0;
> }
>
> Anyone see anything wrong with the testcase?
This testcase is targeting a general purpose register, whereas the issue I'm
presenting gets the stack pointer as base address for many memory operations
targeting the same offset from this base address. So strictly speaking, I think
the two cases are slightly different.
Thanks,
Mathieu
> Do we thing this sort of thing
> ought to work, perhaps with scopes lengthened?
>
>
> r~
>
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
Re: [lttng-dev] Multiple local register variables w/ same register
- Original Message -
> From: "Mathieu Desnoyers"
> To: "Richard Henderson"
> Cc: "Jakub Jelinek" , gcc@gcc.gnu.org, "Peter Zijlstra"
> , "Catalin Marinas"
> , "Nathan Lynch" ,
> linux-ker...@vger.kernel.org, "Will Deacon"
> , lttng-...@lists.lttng.org, "Andrew Morton"
> , "Paul E. McKenney"
> , "Linus Torvalds"
> Sent: Tuesday, November 19, 2013 5:25:18 PM
> Subject: Re: [lttng-dev] Multiple local register variables w/ same register
>
> - Original Message -
> > From: "Richard Henderson"
> > To: "Peter Zijlstra" , "Mathieu Desnoyers"
> >
> > Cc: "Will Deacon" , linux-ker...@vger.kernel.org,
> > "Catalin Marinas" ,
> > lttng-...@lists.lttng.org, "Nathan Lynch" , "Paul
> > E. McKenney"
> > , "Linus Torvalds"
> > , "Andrew Morton"
> > , "Jakub Jelinek" ,
> > gcc@gcc.gnu.org
> > Sent: Tuesday, November 19, 2013 4:56:57 PM
> > Subject: Multiple local register variables w/ same register
> >
> > On 11/20/2013 03:33 AM, Peter Zijlstra wrote:
> > > On Tue, Nov 19, 2013 at 05:02:20PM +, Mathieu Desnoyers wrote:
> > >> Unfortunately I don't have a ARM cross-compiler setup ready. Nathan
> > >> could
> > >> test
> > >> it for us though.
> > >>
> > >> It might shuffle things around enough to work around the issue, but with
> > >> the
> > >> approach you propose, I would be concerned about the compiler being
> > >> within
> > >> its rights to reorder the code into the following sequence:
> > >>
> > >> struct thread_info *ptra, *ptrb;
> > >>
> > >> ptra = current_thread_info();
> > >> /*
> > >> * each current_thread_info() would have a clobber on *sp, which orders
> > >> * those two wrt each other.
> > >> */
> > >> ptrb = current_thread_info();
> > >>
> > >> load from ptra->preempt_count;
> > >> /*
> > >> * however, the following accesses that depend on ptra and ptrb could be
> > >> * reordered if the compiler has no way to know that ptra and ptrb are
> > >> * aliased.
> > >> */
> > >> store to ptrb->preempt_count;
> > >>
> > >> One question that might be worth asking: with the local register
> > >> variable
> > >> extension
> > >> (http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Local-Reg-Vars.html#Local-Reg-Vars)
> > >> (thanks to Jakub for the pointer), should the compiler consider two
> > >> variables
> > >> bound to the same register as being aliased or not ? AFAIU, local reg
> > >> vars
> > >> appear
> > >> to be architecture-specific, so maybe there is something fishy on ARM ?
> >
> > It appears not:
> >
> > int __attribute__((noinline)) f(void)
> > {
> > {
> > register int x __asm__("eax");
> > x = 1;
> > }
> > {
> > register int y __asm__("eax");
> > return ++y;
> > }
> > }
> >
> > extern void abort(void);
> >
> > int main(void)
> > {
> > if (f() != 2)
> > abort();
> > return 0;
> > }
> >
> > Anyone see anything wrong with the testcase?
>
> This testcase is targeting a general purpose register, whereas the issue I'm
> presenting gets the stack pointer as base address for many memory operations
> targeting the same offset from this base address. So strictly speaking, I
> think the two cases are slightly different.
By the way, I just had more info from Nathan, where a splat clearly shows a
scheduling while atomic, which points rather to an unbalanced preempt
enable/disable within LTTng. It's weird though, because so far it only triggers
on ARM, and only with gcc 4.8.x. Don't waste your time on this one until we can
figure out if the issue is within LTTng.
Thanks,
Mathieu
>
> Thanks,
>
> Mathieu
>
>
> > Do we thing this sort of thing
> > ought to work, perhaps with scopes lengthened?
> >
> >
> > r~
> >
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
>
> ___
> lttng-dev mailing list
> lttng-...@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
