[llvm-dev] struct bitfield regression between 3.6 and 3.9 (using -O0)

[Phil Tomson via llvm-dev]

On Thu, Dec 22, 2016 at 7:11 PM, Friedman, Eli <efriedma at codeaurora.org>
wrote:

> On 12/22/2016 5:45 PM, Phil Tomson wrote:
>
>> Given that this is compiled with -O0, would there a way to skip the
>> Optimization of the Type-legalized selection DAG? It's fine until it
>> optimizes the Type-legalized selection DAG into the Optimized
>> Type-legalized selection DAG.
>>
>
> Umm, I wouldn't really suggest shoving the problem under the rug... I
> mean, turning off the optimization might make this particular testcase work
> the way you want it to, but the problem will still be lurking, waiting to
> be triggered by a different configuration.
>

Possibly, but this testcase is based on distilling some larger libraries
which we found to be failing into this testcase. And we need to move
forward with being able to compile those larger libraries correctly by year
end (they need them with -O0 -g  ie. a debug build otherwise I'd tell them
to just compile with -O2 which works).

Since this is happening after the Type-legalized selection DAG is optimized
and prior to Instruction Selection I'm thinking this is an upstream LLVM
bug and thus won't be fixed in time for us to get done what we need to get
done. Of course I could be wrong about this assessment, how might this be a
target-specific bug?



>
> There are patches floating around to turn off DAGCombine, and various
> parts of it, at -O0; you should be able to find past email threads on
> llvmdev discussing it.  IIRC it causes problems for various targets because
> it exercises different codepaths.


I suspect this is probably the best short-term solution to turn off
DAGCombine if -O0 is specified.

Phil

Is this

>
>
> -Eli
>
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161222/c77e61d1/attachment.html>