[llvm] r180750 - Revert the command line option patch. However, keep the part that makes this pass on Windows. I.e., we don't emit the target dependent attributes in a comment before the function.

Rafael Espíndola rafael.espindola at gmail.com
Tue Apr 30 05:36:20 PDT 2013 

LGTM. Not passing a 64 number around when we don't need one is a good
thing anyway.

On 30 April 2013 01:23, Pasi Parviainen <pasi.parviainen at iki.fi> wrote:
> On 30.4.2013 5:17, Reid Kleckner wrote:
>>
>> On Mon, Apr 29, 2013 at 5:19 PM, Bill Wendling <isanbard at gmail.com> wrote:
>>>
>>> On Apr 29, 2013, at 5:16 PM, Chris Lattner <clattner at apple.com> wrote:
>>>
>>>> On Apr 29, 2013, at 5:14 PM, Bill Wendling <isanbard at gmail.com> wrote:
>>>>>
>>>>> On Apr 29, 2013, at 5:13 PM, Chris Lattner <clattner at apple.com> wrote:
>>>>>
>>>>>> Thanks Bill, shouldn't this also revert this part?
>>>>>>
>>>>>>> /// \brief Return the attributes at the index as a string.
>>>>>>> -  std::string getAsString(unsigned Index, bool InAttrGrp = false)
>>>>>>> const;
>>>>>>> +  std::string getAsString(unsigned Index, bool TargetIndependent =
>>>>>>> true,
>>>>>>> +                          bool InAttrGrp = false) const;
>>>>>>>
>>>>>>> typedef ArrayRef<Attribute>::iterator iterator;
>>>>>>
>>>>>>
>>>>>> Why is this needed on windows?
>>>>>>
>>>>> There is a strange bug on Windows where it doesn't allow me to iterate
>>>>> through the attributes in the way I want. I can try to think up a different
>>>>> way to do it, though…
>>>>
>>>>
>>>> What is the bug?  We want consistent behavior on all hosts.  From your
>>>> description it isn't clear if this is a host or target issue.
>>>>
>>> The bug has to do with an out-of-range value being passed to a vector. I
>>> don't have access to a Windows box, so I can't really figure out if it's a
>>> host or target issue.
>>
>>
>> A messy stack trace with funny Windows paths for everyone:
>>
>> $ ninja llc opt && D:/src/llvm/build_debug/bin/./opt.EXE
>> 'D:\src\llvm\test\Transforms\TailCallElim\setjmp.ll'  -S
>> ninja: no work to do.
>> ninja: warning: multiple rules generate lib\profile_rt.lib. build will
>> not be correct; continuing anyway
>> Assertion failed: begin() + idx < end(), file
>> D:\src\llvm\include\llvm/ADT/SmallVector.h, line 140
>> Stack dump:
>> 0.      Program arguments: D:\src\llvm\build_debug\bin\opt.EXE
>> D:\src\llvm\test\Transforms\TailCallElim\setjmp.ll -S
>> 1.      Running pass 'Print module to stderr' on module
>> 'D:\src\llvm\test\Transforms\TailCallElim\setjmp.ll'.
>> 0x6175C94A (0x0000000A 0x00000000 0x002CF4E8 0x61837114), exit() +
>> 0x13A bytes(s)
>> 0x61847A9C (0x002CF64C 0x002CF4FC 0x0157DAE4 0x00000000), abort() +
>> 0x1C bytes(s)
>> 0x61837114 (0x021FDC78 0x021FDC10 0x0000008C 0x002CF89C), _wassert() +
>> 0xC04 bytes(s)
>> 0x01C6CE70 (0x00000001 0x004EE578 0x002CF52C 0x01C669E5),
>> llvm::SmallVectorTemplateCommon<std::pair<unsigned
>> int,llvm::AttributeSetNode *>,void>::operator[]() + 0x40 bytes(s),
>> d:\src\llvm\include\llvm\adt\smallvector.h, line 140 + 0x31 byte(s)
>> 0x01C6DA1D (0x00000001 0xCCCCCCCC 0xCCCCCCCC 0x002CF62C),
>> llvm::AttributeSetImpl::begin() + 0x1D bytes(s),
>> d:\src\llvm\lib\ir\attributeimpl.h, line 252 + 0x1D byte(s)
>> 0x01C669E5 (0x00000001 0x002CF76C 0x002CF89C 0xFFFFFFFF),
>> llvm::AttributeSet::begin() + 0x45 bytes(s),
>> d:\src\llvm\lib\ir\attributes.cpp, line 870
>> 0x01BE62BE (0x00508C68 0x002CF86C 0xCCCCCCCC 0xCCCCCCCC), `anonymous
>> namespace'::AssemblyWriter::printFunction() + 0x11E bytes(s),
>> d:\src\llvm\lib\ir\asmwriter.cpp, line 1618 + 0xE byte(s)
>> 0x01BE5337 (0x004EE658 0x002CF958 0xCCCCCCCC 0x002CF7DC), `anonymous
>> namespace'::AssemblyWriter::printModule() + 0x417 bytes(s),
>> d:\src\llvm\lib\ir\asmwriter.cpp, line 1378 + 0x14 byte(s)
>> 0x01BE102B (0x004E8E80 0x00000000 0x002CF890 0x01C4E2CA),
>> llvm::Module::print() + 0x6B bytes(s),
>> d:\src\llvm\lib\ir\asmwriter.cpp, line 2172
>> 0x011E12A1 (0x004E8E80 0x004EE658 0x004FBF98 0x002CF958),
>> llvm::operator<<() + 0x11 bytes(s),
>> d:\src\llvm\include\llvm\ir\module.h, line 584
>> 0x01C4E2CA (0x004EE658 0x002CFD6C 0x002CF964 0x00000000), `anonymous
>> namespace'::PrintModulePass::runOnModule() + 0x2A bytes(s),
>> d:\src\llvm\lib\ir\printmodulepass.cpp, line 40 + 0x1C byte(s)
>> 0x01BFC1D9 (0x004EE658 0x00000000 0x7EFDE000 0xCCCCCCCC),
>> llvm::MPPassManager::runOnModule() + 0x1C9 bytes(s),
>> d:\src\llvm\lib\ir\passmanager.cpp, line 1608 + 0x17 byte(s)
>> 0x01BFC7F1 (0x004EE658 0x002CFBA0 0x002CFD6C 0x0105FF07),
>> llvm::PassManagerImpl::run() + 0x101 bytes(s),
>> d:\src\llvm\lib\ir\passmanager.cpp, line 1703 + 0x1B byte(s)
>> 0x01BFB21D (0x004EE658 0x00000000 0x00000000 0xCCCCCCCC),
>> llvm::PassManager::run() + 0x1D bytes(s),
>> d:\src\llvm\lib\ir\passmanager.cpp, line 1739
>> 0x0105FF07 (0x00000003 0x004E7ED8 0x004E1D58 0x13088E0F), main() +
>> 0x14D7 bytes(s), d:\src\llvm\tools\opt\opt.cpp, line 827
>> 0x01E30449 (0x002CFDD0 0x757133AA 0x7EFDE000 0x002CFE10),
>> __tmainCRTStartup() + 0x199 bytes(s),
>> f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c, line 536 + 0x19
>> byte(s)
>> 0x01E3058D (0x7EFDE000 0x002CFE10 0x77AE9EF2 0x7EFDE000),
>> mainCRTStartup() + 0xD bytes(s),
>> f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c, line 377
>> 0x757133AA (0x7EFDE000 0x71AE5B0C 0x00000000 0x00000000),
>> BaseThreadInitThunk() + 0x12 bytes(s)
>> 0x77AE9EF2 (0x01E30580 0x7EFDE000 0x00000000 0x00000000),
>> ___RtlUserThreadStart at 8() + 0x70 bytes(s)
>> 0x77AE9EC5 (0x01E30580 0x7EFDE000 0x00000000 0x00000000),
>> __RtlUserThreadStart at 8() + 0x1B bytes(s)
>>
>> I wasn't able to get to this today, but hopefully I can figure this
>> out tomorrow.
>>
>
> This problem is caused by following code within
> AssemblyWriter::printFunction:
>
>     unsigned Idx = 0;
>     for (unsigned E = AS.getNumSlots(); Idx != E; ++Idx)
>       if (AS.getSlotIndex(Idx) == AttributeSet::FunctionIndex)
>         break;
>
> Disassembly reveals following:
>
>               if (AS.getSlotIndex(Idx) == AttributeSet::FunctionIndex)
> 0x141050392  <+0x0152>         mov     edx,dword ptr [rsp+0B4h]
> 0x141050399  <+0x0159>         lea     rcx,[rsp+68h]
> 0x14105039e  <+0x015e>         call opt!llvm::AttributeSet::getSlotIndex
> (00000001`411994d0)
> 0x1410503a3  <+0x0163>         cmp     rax,0FFFFFFFFFFFFFFFFh
> 0x1410503a7  <+0x0167>         jne     opt!`anonymous
> namespace'::AssemblyWriter::printFunction+0x16b (00000001`410503ab)
>                 break;
> 0x1410503a9  <+0x0169>         jmp     opt!`anonymous
> namespace'::AssemblyWriter::printFunction+0x16d (00000001`410503ad)
>
> getSlotIndex return type is uint64_t, but the underlying SlotIndex is
> actually unsigned type. The enumerator value FunctionIndex is defined as
> FunctionIndex = ~0U. Now looking at disassembled code it seems like compiler
> has widened FunctionIndex with sign extension. With this information we can
> conclude that the loop doesn't find the correct slot, since compared values
> never match.
>
> Attached patch should fix the issue by matching interface with underlying
> type.
>
> Pasi.
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>

More information about the llvm-commits mailing list