Re: Tree SSA If-combine optimization pass in GCC
On Tue, Feb 17, 2015 at 5:24 PM, Ajit Kumar Agarwal
wrote:
>
>
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, February 17, 2015 5:49 PM
> To: Ajit Kumar Agarwal
> Cc: gcc@gcc.gnu.org; Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida;
> Nagaraju Mekala
> Subject: Re: Tree SSA If-combine optimization pass in GCC
>
> On Tue, Feb 17, 2015 at 11:26 AM, Ajit Kumar Agarwal
> wrote:
>>
>>
>> -Original Message-
>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>> Sent: Tuesday, February 17, 2015 3:42 PM
>> To: Ajit Kumar Agarwal
>> Cc: gcc@gcc.gnu.org; Vinod Kathail; Shail Aditya Gupta; Vidhumouli
>> Hunsigida; Nagaraju Mekala
>> Subject: Re: Tree SSA If-combine optimization pass in GCC
>>
>> On Tue, Feb 17, 2015 at 9:22 AM, Ajit Kumar Agarwal
>> wrote:
>>> Hello All:
>>>
>>> I can see the IF-combining (If-merging) pass of optimization on tree-ssa
>>> form of intermediate representation.
>>> The IF-combine or merging takes of merging the IF-THEN-ELSE if the
>>> condition Expr found be congruent or Similar.
>>>
>>> The IF-combine happens if the two IF-THEN-ELSE are contiguous to each other.
>>> If the IF-THEN-ELSE happens to be not contiguous but are wide apart with
>>> there is code in between.
>>> Does the If-combine takes care of this. This requires to do the
>>> head-duplication and Tail-duplication for the Code in between If-THEN-ELSE
>>> to bring the IF-THEN-ELSE contiguous to each other.
>>>
>>> After the head and tail duplication of the code in between the
>>> IF-THEN-ElSE sequence becomes contiguous to each other. Apart from
>>> this, Does the tree-ssa-if-combine pass considers the control flow of the
>>> body of the IF-THEN-ELSE. Is there any limitation on control flow of the
>>> body of the IF-THEN-ELSE.
>>>
>>> Can I know the scope of tree-ssa-ifcombine optimizations pass with respect
>>> to the above points.
>>>
>>> Thoughts Please?
>>
if-combine is a simple CFG + condition pattern matcher. It does not
perform head/tail duplication. Also there is no "control flow" in the
bodies, control flow is part of the CFG that is >>matched so I'm not quite
getting your last question.
>>
>> Thanks ! My last question was If there is a control flow likes loops
>> inside the IF-THEN-ELSE, which could be possible if the Loop
>> unswitching is performed and the Loop body is placed inside the
>> IF-THEN-ELSE, then in that case the two IF-THEN-ELSE can be merged if the
>> cond expr matches and the control flow of the body of If-then-else matches?
>>
>> There are many cases in SPEC 2006 benchmarks where the IF-combine
>> could be enabled if the if-then-else sequence is made contiguous by
>> performing the head/tail duplication.
>
>>>I'd be curious what those cases look like. Care to file some bugreports
>>>with testcases?
>
> This is not a bug and it’s the performance improvement optimizations with
> respect to h264ref spec2006 benchmarks. Here is the example.
>
>
> Var1 = funcptr();
> For(...)
> {
>Code here
> For(...)
> {
> Code here ...
> For(...)
>... code here..
>
> If(*funcptr() == FastPely())
>FastPely()
> Else
> (*funcptr)();
>
> There are such 16 IF statements.
>
>
> code here
>
> } end for
> Code here
> }//end for
> Code here
> }//end for.
>
> The funcptr has two targets FastPely() and UMVPely(). After the indirect call
> promotion the targets is known to be either Fastpely() or UMVPely.
>
> The Transformed code after indirect icall promotion looks like as follows.
>
> Var1 = funcptr();
> For(...)
> {
>Code here
> For(...)
> {
> Code here ...
> For(...)
>... code here..
>
> If(var1 == FastPely())
>FastPely()
> Else
> UMVpely();
>
> There are such 16 IF statements.
So literally adjacent
if (var1 == FastPely)
FastPely();
else
UMVpely();
if (var1 == FastPely)
FastPely();
else
UMVpely();
...
? Like if from a manually unrolled loop? It would be interesting to
get a re-rolling facility in GCC. So you'd transform the above to
if (var1 == FastPely)
{
FastPely();
FastPely();
...
}
else
{
UMVpely();
UMVpely();
}
? Note that jump threading should perform this kind of optimization
already. It would be interesting to have a real testcase that can be
compiled - please open an enhancement bugreport.
Richard.
>
>
> code here
>
> } end for
> Code here
> }//end for
> Code here
> }//end for.
>
> After the icall promotion the Function FastPely or UMVPely can be inlined as
> the target is known to be either Fastpely() or UmvPely() and it become a
> candidate for heuristics for inlined.
> As you can see the transformed code the IF-THEN-ELSE (such 16 If statements)
> can be IF-comb
Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference
Starting with gcc 4.9, -O2 implicitly invokes -fisolate-erroneous-paths-dereference: which https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html documents as Detect paths that trigger erroneous or undefined behavior due to dereferencing a null pointer. Isolate those paths from the main control flow and turn the statement with erroneous or undefined behavior into a trap. This flag is enabled by default at -O2 and higher. This results in a sizable number of previously working embedded programs mysteriously crashing when recompiled under gcc 4.9. The problem is that embedded programs will often have ram starting at address zero (think hardware-defined interrupt vectors, say) which gets initialized by code which the -fisolate-erroneous-paths-deference logic can recognize as reading and/or writing address zero. What happens then is that the previously running program compiles without any warnings, but then typically locks up mysteriously (often disabling the remote debug link) due to the trap not being gracefully handled by the embedded runtime. Granted, such code is out-of-spec wrt to C standards. None the less, the problem is quite painful to track down and unexpected. Is there any good reason the -fisolate-erroneous-paths-dereference logic could not issue a compiletime warning or error, instead of just silently generating code virtually certain to crash at runtime? Such a warning/error would save a lot of engineers significant amounts of time, energy and frustration tracking down this problem. I would like to think that the spirit of gcc is about helping engineers efficiently correct nonstandard pain, rather than inflicting maximal pain upon engineers violating C standards. :-) -Jeff BTW, I'd also be curious to know what is regarded as engineering best practice for writing a value to address zero when this is architecturally required by the hardware platform at hand. Obviously one can do various things to obscure the process sufficiently that the current gcc implementation won't detect it and complain, but as gcc gets smarter about optimization those are at risk of failing in a future release. It would be nice to have a guaranteed-to-work future-proof idiom for doing this. Do we have one, short of retreating to assembly code?
Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference
On Wed, Feb 18, 2015 at 11:21:56AM -0800, Jeff Prothero wrote: > Starting with gcc 4.9, -O2 implicitly invokes > > -fisolate-erroneous-paths-dereference: > > which > > https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html > > documents as > > Detect paths that trigger erroneous or undefined behavior due to > dereferencing a null pointer. Isolate those paths from the main control > flow and turn the statement with erroneous or undefined behavior into a > trap. This flag is enabled by default at -O2 and higher. > > This results in a sizable number of previously working embedded programs > mysteriously > crashing when recompiled under gcc 4.9. The problem is that embedded > programs will often have ram starting at address zero (think hardware-defined > interrupt vectors, say) which gets initialized by code which the > -fisolate-erroneous-paths-deference logic can recognize as reading and/or > writing address zero. If you have some pages mapped at address 0, you really should compile your code with -fno-delete-null-pointer-checks, otherwise you can run into tons of other issues. Also, there is -fsanitize=undefined that allows discovery of such invalid calls at runtime, though admittedly it isn't supported for all targets. Jakub
Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference
On Wed, Feb 18, 2015 at 11:21 AM, Jeff Prothero wrote: > > Starting with gcc 4.9, -O2 implicitly invokes > > -fisolate-erroneous-paths-dereference: > > which > > https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html > > documents as > > Detect paths that trigger erroneous or undefined behavior due to > dereferencing a null pointer. Isolate those paths from the main control > flow and turn the statement with erroneous or undefined behavior into a > trap. This flag is enabled by default at -O2 and higher. > > This results in a sizable number of previously working embedded programs > mysteriously > crashing when recompiled under gcc 4.9. The problem is that embedded > programs will often have ram starting at address zero (think hardware-defined > interrupt vectors, say) which gets initialized by code which the > -fisolate-erroneous-paths-deference logic can recognize as reading and/or > writing address zero. You should have used -fno-delete-null-pointer-checks which has been doing this optimization for a long time now, just it got better with -fisolate-erroneous-paths-dereference pass. Thanks, Andrew Pinski > > What happens then is that the previously running program compiles without > any warnings, but then typically locks up mysteriously (often disabling the > remote debug link) due to the trap not being gracefully handled by the > embedded runtime. > > Granted, such code is out-of-spec wrt to C standards. > > None the less, the problem is quite painful to track down and > unexpected. > > Is there any good reason the > > -fisolate-erroneous-paths-dereference > > logic could not issue a compiletime warning or error, instead of just > silently generating code virtually certain to crash at runtime? > > Such a warning/error would save a lot of engineers significant amounts > of time, energy and frustration tracking down this problem. > > I would like to think that the spirit of gcc is about helping engineers > efficiently correct nonstandard pain, rather than inflicting maximal > pain upon engineers violating C standards. :-) > > -Jeff > > BTW, I'd also be curious to know what is regarded as engineering best > practice for writing a value to address zero when this is architecturally > required by the hardware platform at hand. Obviously one can do various > things to obscure the process sufficiently that the current gcc implementation > won't detect it and complain, but as gcc gets smarter about optimization > those are at risk of failing in a future release. It would be nice to have > a guaranteed-to-work future-proof idiom for doing this. Do we have one, short > of retreating to assembly code?
gcc-4.9-20150218 is now available
Snapshot gcc-4.9-20150218 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20150218/ 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 220801 You'll find: gcc-4.9-20150218.tar.bz2 Complete GCC MD5=44c215674c52f6e69a0f08b01c3413bd SHA1=050bfbdea66ddd9d40227ba507076fadb17920a5 Diffs from 4.9-20150211 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.
Thanks
Greetings, My name is MUTOMBO MATANDA "Kyle" Hervé. I am one of the large community of GCC users. It is remarkable how you have written the GCC toolchain especially when we figure out how much time and mental efforts that it requires. It has been 7 years now since my first use of your compiler and I must tell you that I never felt disappointed. Please, go on in your work and keep on improving. -- MUTOMBO MATANDA Kyle +243820989056 16, a.v. De la paix, Binza-UPN, Kinshasa, Democratic Republic of Congo.
