[llvm] r306529 - [X86] Correct dwarf unwind information in function epilogue

[Daniel Jasper via llvm-commits]

Ah, and in case that helps, the internal test we also fails for the
combination of ASAN and PPC only.

On Thu, Jun 29, 2017 at 3:18 PM, Daniel Jasper <djasper at google.com> wrote:

> So you mean this failure one PPC:
> http://lab.llvm.org:8011/builders/sanitizer-ppc64be-
> linux/builds/3112/steps/64-bit%20check-asan/logs/stdio
>
> FWIW, I think this is the same failure that we see on an internal test we
> have. Would you be open to revert the patch until we can investigate the
> exact cause?
>
>
> On Thu, Jun 29, 2017 at 12:55 PM, Peter Smith via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
>> I've taken a look to see what affect this would have on CFI
>> instructions for AArch64.
>>
>> My understanding concurs with Petar's explanation; that no extra CFI
>> instructions will be added if the default values in MachineBasicBlock
>> are used. I have a small concern that this assumption isn't really
>> obvious from the comments in initializeCFIInfo which leaves open the
>> possibility that someone else might inadvertently break this in the
>> future, although I guess the tests should pick this up fairly quickly
>> if it does.
>>
>> Peter
>>
>> On 29 June 2017 at 11:26, Petar Jovanovic via llvm-commits
>> <llvm-commits at lists.llvm.org> wrote:
>> > + Violeta
>> >
>> >> So, this says "[X86]", but is it really X86-specific? there is a pretty
>> >> huge set of changes to common CFI infrastructure that is used by PPC
>> and
>> >> AArch64 at least.
>> >
>> > It is x86-specific in the way that improvements made in this patch
>> should
>> > affect/improve x86 target only. Other arches can benefit if they make
>> > similar changes.
>> >
>> >> It seems like these late passes (that run on all targets from what I
>> can
>> >> tell) *require* the new information to be set up in the basic block...
>> >
>> > Yes, but if the new information is not set (i.e. has default values),
>> the
>> > passes would not make any changes. An alternative is to run these
>> passes for
>> > selected target(s) only.
>> >
>> >> How does this work? Is this not a (serious) bug?
>> >
>> > Violeta has more description in https://reviews.llvm.org/D18046
>> > It should not be a bug, more like a place where things can be improved
>> for
>> > other architectures too.
>> >
>> > So the passes should not be the problem. The only thing I am concerned
>> is
>> > that other common code changes may have side effects elsewhere. There is
>> > a failure on PPC64 sanitizer buildbot and this change is on the blame
>> list,
>> > so that is being investigated along with the case Eli has reported.
>> > _______________________________________________
>> > llvm-commits mailing list
>> > llvm-commits at lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170629/b7619bb9/attachment.html>