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

Daniel Jasper via llvm-commits llvm-commits at lists.llvm.org
Thu Jun 29 06:58:45 PDT 2017


I have done some more checks and am convinced that this patch is breaking
the buildbot. Reverted in r306676.

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

> 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/7b61d7b4/attachment.html>


More information about the llvm-commits mailing list