Re: Is there a way to dump LTO IR?
On Fri, Jan 23, 2015 at 9:26 PM, H.J. Lu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64754 > > is a LTO bug where stage 1 and stage 2 compilers generate > different LTO IR. Is there a way to dump LTO IR to see the > actual difference in LTO IR? No. I've had multiple incarnations of local patches to dump stuff during LTO IR write and LTO IR read so I could match them but never committed anything because all this stuff is in the hot path. I wonder if we can make a GCC plugin do it though, via re-using existing lto/tree-streamer.c and some preprocessor defines that switches between plugin and GCC mode... OTOH I had the idea to make the IL self-descriptive to some extent (in a debug mode, of course). Richard. > Thanks. > > -- > H.J.
Re: Is there a way to dump LTO IR?
On Mon, Jan 26, 2015 at 12:57 AM, Richard Biener wrote: > On Fri, Jan 23, 2015 at 9:26 PM, H.J. Lu wrote: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64754 >> >> is a LTO bug where stage 1 and stage 2 compilers generate >> different LTO IR. Is there a way to dump LTO IR to see the >> actual difference in LTO IR? > > No. I've had multiple incarnations of local patches to dump stuff > during LTO IR write and LTO IR read so I could match them but > never committed anything because all this stuff is in the hot path. > > I wonder if we can make a GCC plugin do it though, via re-using > existing lto/tree-streamer.c and some preprocessor defines that > switches between plugin and GCC mode... > I like this idea. We can extend "objdump -d" to dump LTO IR. -- H.J.
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
FX writes: >> The default BOOT_CFLAGS are: -O2 -g -mdynamic-no-pic >> the libiberty pic build appends: -fno-common (and not even -fPIC) [NB >> -fPIC _won't_ override -mdynamic-no-pic, so that's not a simple way out] >> This means that the PIC library is being built with non-pic relocs. > > config/mh-darwin says that -mdynamic-no-pic is there because it “speeds > compiles by 3-5%”. I don’t think we care about speed when the bootstrap > fails, so can we remove it altogether? Darwin/i686 still doesn't bootstrap without this patch, I believe. Shouldn't it be applied to trunk before GCC 5 ships, rather than leaving that target broken? Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
On 26 Jan 2015, at 14:13, Rainer Orth wrote: > FX writes: > >>> The default BOOT_CFLAGS are: -O2 -g -mdynamic-no-pic >>> the libiberty pic build appends: -fno-common (and not even -fPIC) [NB >>> -fPIC _won't_ override -mdynamic-no-pic, so that's not a simple way out] >>> This means that the PIC library is being built with non-pic relocs. >> >> config/mh-darwin says that -mdynamic-no-pic is there because it “speeds >> compiles by 3-5%”. I don’t think we care about speed when the bootstrap >> fails, so can we remove it altogether? > > Darwin/i686 still doesn't bootstrap without this patch, I believe. > Shouldn't it be applied to trunk before GCC 5 ships, rather than leaving > that target broken? I'll try and post a patch to fix it properly this week.. Iain
Re: organization of C Extensions in manual
On Sun, 25 Jan 2015, David Wohlferd wrote: > >> Arrays and Vectors > >> Designated Inits: Labeling elements of initializers. > > > > I think this one might better be placed in a section on initializers. > > Since the only place 'Designated Inits' can be used is on arrays, placing this > in the 'Arrays and Vectors' section seems appropriate. Designated initializers apply to both array elements and structure and union members. (This is another case that logically would describe (a) that the C99 feature is accepted for older standards; (b) a limited subset is accepted for C++; (c) there's also this legacy pre-standard syntax you may see in existing code but shouldn't used in new code.) -- Joseph S. Myers jos...@codesourcery.com
[website, changes] (was: Re: warning about const multidimensional array as function parameter)
Manuel López-Ibáñez : > On 14 October 2014 01:12, Martin Uecker wrote: > > Converting a pointer to an array to a pointer to a constant array > > is safe. Converting a pointer to a pointer to a pointer to a pointer > > to a constant is not (as the CFAQ points out). > > You are probably right that it is safe. Unfortunately, C considers > invalid cases that are safe and that are allowed by C++ (as mentioned > in that C FAQ). I updated the FAQ with comments by Joseph Myers taken > from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47143 and > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33076. Since my patch to change this has been accepted, could you please update the FAQ again? I would suggest to change the paragraph starting with "You are passing.." to: "You are passing int (*)[3] to const int (*)[3], which is not correct according to the C standard. You can disable the warning with -Wno-incompatible-pointer-types. Starting with version 5, gcc only warns about this when using '-pedantic'." And then I would suggest to simply remove everything afterwards because it refers to pointers-to-pointers and not pointers-to-arrays. --- Also, I think the change could be mentioned here: https://gcc.gnu.org/gcc-5/changes.html Suggested text: "gcc will not warn about incompatible pointers types anymore when passing a pointer to an array as a pointer to a constant array or vice versa (except when using '-pedantic'). Instead,it will emit a new warning only if the 'const' qualifier is lost (see '-Wno-discarded-array-qualifiers')." Cheers, Martin
Re: Rematerialization and Live Range Splitting on Region Frequency
On 2015-01-25 4:55 AM, Ajit Kumar Agarwal wrote: Hello All: Looks like Live range splitting and rematerialization are connected to each other. If the boundary of Live range Splitting is in the high frequency of the region then the move connected to splitted live ranges are inside the High frequency region which is the performance bottleneck for many benchmarks. Live range splitting based on the frequency of the region should be considered. The Live range splitting in the High frequency region is beneficial if the splitted live range is assigned the color(hard registers) which is better Spilling inside the high frequency region, although there will be move instruction or shuffle code which is still Better. If one of the splitted live range does not have any use points and all the partner live ranges gets the Hard register, then the move instruction due to splitting will be costly for the high frequency region. In such Case the split point should be move up at the boundary of the transition from low frequency region to high Frequency region, and the splitted live ranges still get hard registers. This require increment check of colorabity which increases the compile time but beneficial with respect to run time. The above heuristic should be incorporated on top of the below Live range splitting Algorithm. Live range splitting algorithm should consider the blocks in the decreasing order of frequency with the first block should be taken from the high frequency region and incrementally updates till it become colorable. Thus split points should be at the edge of the transition from high frequency to low frequency region or from low frequency region to high frequency region. The above Live range splitting should be incorporated for all the flavors of Graph Coloring. Regarding the rematerialization the Chaitin's Rematerialization try to recalculate the expression at all the Use points of the Live ranges and Simpson based approach for Rematerialized try to move the arithmetic Instruction lower to use points or the basic blocks considering the operands of Arithmetic instructions is Not touched along the blocks of the Live range. Considering all the effects of rematerialization, The remat point or the recalculation should be done at the split points instead of Chaitin's approach of remat at every use points and the Simpson approach of operands not being touched upon and the movement of arithmetic instruction later at the use points. The above approaches looks feasible to implement consider the high frequency region into consideration. Thoughts Please ? Ajit, nobody can tell you for sure what the final results of your proposal can be. I usually try a lot of things and most of them are rejected because the results are not what I expected. I personally implemented Simpson's register pressure decrease through rematerialization twice. The first time was long ago (as I remember > 10 years ago) and that time it worked not bad (as I remember it gave 1% for x86 - you can find the exact data in my GCC summit paper "Fighting register pressure in GCC"). It worked well because the old RA was quite bad (imho the problem of most research articles in compiler optimization field was/is in usage of some sub-par compiler where a new good optimization shines in environment of existing simple ones or because of absence of many other optimizations). Second time I reimplemented CFG-sensitive rematerialization (as a separate pass) last year and the results were worse than without it. Therefore I had to implement a rematerialization subpass in LRA which really improves the code. That is because the current RA is pretty good. Even if we have register pressure evaluation (which was absent in the old RA), I believe it is very inaccurate as IR uses a sophisticated coloring criteria which are actually based on dynamic intersected register classes (more accurately approximated by dynamic register class inclusion tree). Also it is very hard to predict a lot of decisions in LRA too. All the above is also true for the live range splitting implemented as a separate pass. There is a good point in your email that rematerialization should work better when it is done not for each use but for some region of uses (and actually Simpon's approach implements it). I guess if you can implement this idea in IRA framework and not as a separate pass, it might give some improvements. The same probably would be true for splitting in IRA environment. Actually IRA was designed to work for tree of any regions including BB. Currently it is only loops and a lot of was done to minimize # of considered loops as a lot of people were not happy with RA speed on some tests. The minimization is based on register pressure evaluation and as I wrote it is not accurate. Including all loops and BB (or may be SESE or other) could improve the code but make the compiler slower. On one ha
Re: Optimal Coalescing with respect to move instruction for Live range splitting
On 2015-01-18 12:37 AM, Ajit Kumar Agarwal wrote: Register allocation with two phase approach does optimal coalescing after the spilling. Sometime Live range splitting makes the coalescing non optimal. The splitted Live range are connected by move instruction. Thus the Live range splitting and more specifically aggressive Live range splitting increases the number of move instruction and making the coalescing non optimal. The optimal coalescing should take the frequency of the regions into consideration. The more the frequency of the region the cost associated with the splitted live ranges will increase. If such cost increasing then we should do aggressive coalescing in this case and remove the move instruction by associating the same color or hard registers associated with move instruction for the splitting live ranges. I am think of adding such heuristics in the GCC Top Down Region based register allocator for the optimal coalescing, thereby reducing the move instruction connected with the splitted Live ranges in the more frequently code. Thoughts please ? It is difficult for me to understand what and how you will do this exactly. If it is not a big work to implement this heuristic, I guess you should try and see the result. If it works we can add it to the RA.
array bounds, sanitizer, safe programming, and cilk array notation
Hi all,
I am writing numerical code, so I am trying to make the use
of arrays in C (with gcc) suck a bit less. In general, the long term
goal would be to have either a compile-time warning or the possibility
to get a run-time error if one writes beyond the end of an array as
specified by its type.
So one example (see below) I looked at is where I pass an array of
too small size to a function, to see how see can be diagnosed. In some
cases, we can get a runtime error with the address sanitizer, but this
is fairly limited (e.g. it does not work when the array is embedded
in a struct) and I also got mixed results when the function
is inlined.
For pointers to arrays with static size one can get an "incompatible
pointer" warning - which is nice. With clang, I also get warning for
pointers which are declared as array parameters and use the 'static'
keyword to specify a minimum size. This a diagnostic we are currently
missing.
The next step would be to have diagnostics also for the VLA
case if the size is known at compilation time (as in the
example below) and a run-time error when it is not (maybe
with the undefined behaviour sanitizer?).
If we have the later, I think this might also help with safer
programming in C, because one would get either a compile time or
runtime error when I passing a buffer which is too small to
a function. For example, snprintf could have a prototype like
this:
int snprintf(size_t size; char str[static size], size_t size,
const char *format, ...);
That VLAs essentially provide the bounded pointer type C is
missing has been pointed out before, e.g. there was a proposal
by John Nagle, although he proposed rather intrusive language
changes (e.g. adding references to C) which are not necessary
in my opinion:
https://gcc.gnu.org/ml/gcc/2012-08/msg00360.html
Finally, what is missing is a way to diagnose problems inside
the called functions. -Warray-bounds=2 (with my recently
accepted patch) helps with this, but - so far - only for static
arrays:
void foo(int (*x)[4])
{
(*x)[4] = 5;// warning
}
It would be nice to also have these warning and runtime errors
(with the undefined behaviour sanitizer) for VLAs.
Finally, I think we should have corresponding warning also
for pointers which are declared as array parameters:
void foo2(int x[4])
{
x[4] = 5;
}
The later does not currently produce a warning, because x
is converted to a pointer and the length is ignored.
If it is not possible to have warning here for compatibility
reasons, one possibility is to have an extension similar to
'static' which makes 'x' a proper array in the callee, e.g.
something like:
void foo2(int x[array 4])
{
// x is now of type int[4] and not int*
x[4] = 5; // error
}
The semantics would be that the array is still passed as
a pointer but the type of x would be int[4]. Because it
immediately decays into a pointer when used, no code generation
changes would be required (except maybe when looking at the
type with sizeof and _Generic).
Another reason I like this is because Cilk array notation
currently requires the length to be specified for 'x' because
it is a pointer and not an array. If x would be an array,
something like this would work:
void foo2(int x[array 4])
{
x[:] = 1;
}
In fact, the documentation for Cilk as such examples
(without the array keyword), and I guess this works on the
intel compiler but not on gcc.
I am willing to spend some (limited) time on all of this, but
I thought I ask for comments first. I appreciate any feedback,
suggestions, and help!
Cheers,
Martin
// file 1
extern void bar(int x[static 5])
{
for (int i = 0; i < 5; i++)
x[i] = 1;
}
extern void bar2(int (*x)[5])
{
for (int i = 0; i < 5; i++)
(*x)[i] = 1;
}
// file 2
#include
extern void bar(int x[static 5]);
extern void bar2(int (*x)[5]);
int main()
{
int x[4] = { 0 };
bar(x); // warning only with clang (found by asan)
bar2(&x); // warning (found by asan)
int c = 4;
int y[c];
for (int i = 0; i < c; i++)
y[i] = 0;
bar(y); // not diagnosed (found by asan)
bar2(&y); // not diagnosed (found by asan)
struct foo {
int z[4];
int bar;
} zz = { { 0 }, 0 };
bar(zz.z); // warning only with clang
bar2(&zz.z);// warning
printf("%d %d %d %d\n", x[0], x[1], x[2], x[3]);
printf("%d %d %d %d\n", y[0], y[1], y[2], y[3]);
printf("%d %d %d %d\n", zz.z[0], zz.z[1], zz.z[2], zz.z[3]);
}
Re: Help with reload bug, please
On 01/23/15 14:46, Andrew Stubbs wrote: SECONDARY_INPUT_RELOAD_CLASS is another missed opportunity. Just like the legitimate address stuff, this has checks for the various VFP classes, but reload detects the class in the same flawed way, so an integer reload gives GENERAL_REGS even when the destination is VFP. Within the macro there's no way to see the whole insn. You have to be conservative here. It's part of the fundamental design issue you're trying to work around. We may have used special constraints as well to allow loads/stores of integer registers in FP modes to use the larger offset. Do you have an example? The entire PA port? :-) Note this was a huge issue on the PA because integer multiply was implemented in the FP unit, so we regularly had integer mode accesses to FP registers. If you don't have similar needs, I think there's some further macros you can define to discourage that behaviour. I just can't remember what they are. I'd focus on the bits that determine that an address is legitimate or not and the secondary reload mechanism. Also note that the allowed offsets were increased in the PA 2.0 so you have to filter out that while you're reading. Jeff
Re: [rvskmbr...@gmail.com: Re: Type-in programs using BASH]
> I am proposing this as a possible alternative or complement to publication > on the Internet to take into account those without Internet access, though > those *with* Internet access also get the benefit. So you want to publish stuff on the Internet for people that don't have access to the Internet? Right. This all sounds like a waste of time. Don't type machine code. Also, in the remote case that people will type machine code into their terminal, what does heredocs have to do with that? Bash doesn't understand machine code.
Re: [website, changes] (was: Re: warning about const multidimensional array as function parameter)
On 26 January 2015 at 19:15, Martin Uecker wrote: > > Since my patch to change this has been accepted, could you please > update the FAQ again? Done. Moreover, if you create a wiki account, I will grant you editing powers. > Also, I think the change could be mentioned here: > > https://gcc.gnu.org/gcc-5/changes.html I agree. That requires to produce a patch against our wwwdocs: https://gcc.gnu.org/contribute.html#webchanges and getting it accepted as usual. Thus I would let you (or someone else) handle it. One nit: I'd suggest to use -Wpedantic rather than -pedantic, for consistency with other -W* options. Thanks for following up on this. Cheers, Manuel.
Why is floor() only compiled to roundsd when using -funsafe-math-optimizations?
Dear list,
Consider the following small program:
#include
#include
#include
int main(int argc, char **argv)
{
double a;
a = strtod(argv[0], NULL);
printf("%f\n", floor(a));
return(0);
}
When compiling this with a -march that supports the roundsd instruction,
the floor() call seems to only be compiled to such an instruction if
-funsafe-math-optimizations is specified.
Why is this? I notice the glibc's floor() implementation (for
SSE4.1-enabled processors) consists of only this instruction, so barring a
bug in glibc, that would seem to imply to me the roundsd is IEEE-compliant
and safe. Why does GCC consider it unsafe?
For reference, these are the complete compile commands I'm using to test:
gcc -O -march=haswell -c -S -o test.s test.c
vs.
gcc -O -funsafe-math-optimizations -march=haswell -c -S -o test.s test.c
--
Fredrik Tolf
Re: [rvskmbr...@gmail.com: Re: Type-in programs using BASH]
No, no, not on the Internet---I mean in a paper magazine, which Internet users can also get. I'd like the machine code discussion to end. -- Sent from my iPod On Jan 26, 2015, at 3:03 PM, Eduardo A. Bustamante López wrote: >> I am proposing this as a possible alternative or complement to publication >> on the Internet to take into account those without Internet access, though >> those *with* Internet access also get the benefit. > So you want to publish stuff on the Internet for people that don't have access > to the Internet? Right. > > This all sounds like a waste of time. Don't type machine code. Also, in the > remote case that people will type machine code into their terminal, what does > heredocs have to do with that? Bash doesn't understand machine code.
Re: array bounds, sanitizer, safe programming, and cilk array notation
On Mon, 26 Jan 2015, Martin Uecker wrote: > extern void bar2(int (*x)[5]); > int c = 4; > int y[c]; > bar2(&y); // not diagnosed (found by asan) This is the undefined behavior "If the two array types are used in a context which requires them to be compatible, it is undefined behavior if the two size specifiers evaluate to unequal values." (C11 6.7.6.2#6). Yes, it would make sense for ubsan to detect this. Generally, most forms of runtime undefined behavior listed in J.2 should have ubsan detection unless hard to detect / detected by some other sanitizer such as asan. Does adding new forms of sanitization require upstream libsanitizer changes as well or can arbitrary ubsan checks be added without needing libsanitizer changes? -- Joseph S. Myers jos...@codesourcery.com
Re: [rvskmbr...@gmail.com: Re: Type-in programs using BASH]
I would also like the discussion on the GCC mailing list to end. The discussion on /source/ code, however, should remain alive and well. Sorry for all the confusion. And by "type-in programs", I don't mean example programs like "Hello world" programs. I mean real programs with real purpose. Programs written by freelance authors that program for a living, to (hopefully) find a user base among even the newest of GNU/Linux users. One day we'll be able to type in programs like these that are encoded in machine code. But that day is not now. For portability reasons, I'd prefer source code for print publication. But, in case we ever reach that day, I won't modify my proposed GPL addendum on this topic. This discussion is on a Bash mailing list, but for the same reason as above, it could be possible that a type-in program is published in a source code language, like C, that /compiles/ into machine language. In that case, it would have to be typed into a text editor instead of a here-document (unless your compiler supports reading input from here-documents). As I pointed out to Mr. Stallman, I'd like to encourage everyone who reads these messages to spread the word about the idea. -- Sent from my iPod > On Jan 26, 2015, at 3:50 PM, Ryan Cunningham wrote: > > No, no, not on the Internet---I mean in a paper magazine, which Internet > users can also get. > > I'd like the machine code discussion to end. > > -- > Sent from my iPod > > On Jan 26, 2015, at 3:03 PM, Eduardo A. Bustamante López > wrote: > >>> I am proposing this as a possible alternative or complement to publication >>> on the Internet to take into account those without Internet access, though >>> those *with* Internet access also get the benefit. >> So you want to publish stuff on the Internet for people that don't have >> access >> to the Internet? Right. >> >> This all sounds like a waste of time. Don't type machine code. Also, in the >> remote case that people will type machine code into their terminal, what does >> heredocs have to do with that? Bash doesn't understand machine code.
