[llvm-branch-commits] Deleted Mips symbols in the 3.5 branch

Tue Dec 2 18:15:49 PST 2014

On 12/02/2014 05:54 PM, Daniel Sanders wrote:
> I could be completely off-track here, but my initial attempts at using abi-compliance-checker on a subset of the public headers (everything in $prefix/include/llvm/Target, and $prefix/include/llvm/ExecutionEngine/ExecutionEngine.h) haven't reported anything other than --prefix related differences and this got me thinking.
>
> We only need to worry about symbols that the user can directly access from the definitions in the public (installed) headers and not the whole symbol table, don't we? These symbols are in the symbol table for the shared library, but as far as I can tell there is no definition in the public headers that could enable a user to directly reference anything from $srcdir/lib/Target/Mips (not even the create* functions).
>

This is a good point, and I think you are right about this.  I have been
using the ABI checker with -objects-only so it wasn't considering the
headers at all.  I think we are probably OK then with these deleted symbols
for now, thanks for looking into this and sorry you had to be the guinea pig.

I will try to get the ABI checker to consider the headers too.  I had some
trouble with this last time, but maybe a newer gcc will help.

-Tom

> ________________________________________
> From: Daniel Sanders
> Sent: 02 December 2014 17:02
> To: Tom Stellard; Stellard, Thomas; llvm-branch-commits at cs.uiuc.edu
> Subject: RE: Deleted Mips symbols in the 3.5 branch
>
> ________________________________________
>> From: Tom Stellard [thomas.stellard at amd.com]
>> Sent: 02 December 2014 16:49
>> To: Daniel Sanders; Stellard, Thomas; llvm-branch-commits at cs.uiuc.edu
>> Subject: Re: Deleted Mips symbols in the 3.5 branch
>>
>> On 12/02/2014 11:46 AM, Daniel Sanders wrote:
>>>> From: Tom Stellard [thomas.stellard at amd.com]
>>>> Sent: 02 December 2014 16:27
>>>> To: Daniel Sanders; Stellard, Thomas; llvm-branch-commits at cs.uiuc.edu
>>>> Subject: Re: Deleted Mips symbols in the 3.5 branch
>>>>
>>>> On 12/02/2014 11:25 AM, Daniel Sanders wrote:
>>>>> I've re-added these functions in my working copy but it's had no effect on the symbol table for libLLVM-3.5.so.
>>>>> It looks like the compiler (or perhaps the linker?) is deleting them because they are unused private members of
>>>>> the MipsTargetLowering and MipsCC classes.
>>>>>
>>>>
>>>> I think they need to be public members to show up in the symbol table.
>>>> Were they public before?
>>>>
>>>> -Tom
>>>
>>> On double-checking, I did have a small mistake here but fixing it hasn't helped.
>>>
>>> The member functions of MipsTargetLowering were private before the patch series. MipsCC was a protected class inside MipsTargetLowering. The member functions of MipsCC were public.
>>>
>>> After matching this, the symbol table is still unchanged between the a clean checkout of the release_35 branch and my current working copy that tries to bring these symbols back.
>>>
>>
>> Ok, can you send me these patches.
>>
>> -Tom
>>
>
> Sure, attached.
>
>>>> -----Original Message-----
>>>> From: Stellard, Thomas [mailto:Tom.Stellard at amd.com]
>>>> Sent: 02 December 2014 00:25
>>>> To: Daniel Sanders; llvm-branch-commits at cs.uiuc.edu
>>>> Subject: RE: Deleted Mips symbols in the 3.5 branch
>>>>
>>>> I don't think it maters whether the function bodies are empty, or if they have
>>>> llvm_unreachable().  Though, I think it would be easier to use
>>>> llvm_unreachable(), since you wouldn't have to worry about the return type.
>>>>
>>>>
>>>>
>>>> -Tom
>>>> ________________________________________
>>>> From: Daniel Sanders [Daniel.Sanders at imgtec.com]
>>>> Sent: Monday, December 01, 2014 6:39 PM
>>>> To: Stellard, Thomas; llvm-branch-commits at cs.uiuc.edu
>>>> Subject: RE: Deleted Mips symbols in the 3.5 branch
>>>>
>>>> Hi,
>>>>
>>>> Thanks for the list. Most of these seem to be related to the MipsCC class
>>>> which was removed during the refactoring portions of the patch series. IIRC,
>>>> MipsCC was only used for a local in a few functions such as
>>>> LowerFormalArguments() so it probably shouldn't have been public in the
>>>> first place, but I'll re-add them in the morning anyway. Just to double check,
>>>> when you say 'add them back as no-ops' do you mean with empty function
>>>> bodies, or with llvm_unreachable() inside them?
>>>>
>>>> ________________________________________
>>>> From: Tom Stellard [thomas.stellard at amd.com]
>>>> Sent: 01 December 2014 16:33
>>>> To: Daniel Sanders; llvm-branch-commits at cs.uiuc.edu
>>>> Subject: Deleted Mips symbols in the 3.5 branch
>>>>
>>>> Hi Daniel,
>>>>
>>>> r223008 to r223037 have deleted some public symbols, which will need to be
>>>> added back to maintain ABI compatibility. I'm not sure, but I think some of
>>>> these may be generated by TableGen.
>>>>
>>>> If these functions are no longer used, you can add them back as no-ops if
>>>> that is easier.  Sorry I overlooked this during my review.  Here are the
>>>> deleted symbols:
>>>>
>>>> _ZN4llvm18MipsTargetLowering6MipsCC12allocateRegsERNS0_12ByValArgIn
>>>> foEjj
>>>> _ZNK4llvm18MipsTargetLowering6MipsCC10fixedArgFnEv
>>>> _ZN4llvm18MipsTargetLowering6MipsCC14handleByValArgEjNS_3MVTES2_
>>>> NS_11CCValAssign7LocInfoENS_3ISD10ArgFlagsTyE
>>>> _ZNK4llvm18MipsTargetLowering6MipsCC10shadowRegsEv
>>>>
>>>> _ZNK4llvm18MipsTargetLowering12passByValArgENS_7SDValueENS_5SDLoc
>>>> ERSt5dequeISt4pairIjS1_ESaIS5_EERNS_15SmallVectorImplIS1_EES1_PNS_16
>>>> MachineFrameInfoERNS_12SelectionDAGES1_RKNS0_6MipsCCERKNS0_12By
>>>> ValArgInfoERKNS_3ISD10ArgFlagsTyEb
>>>> _ZNK4llvm18MipsTargetLowering6MipsCC13analyzeReturnERKNS_15SmallVe
>>>> ctorImplINS_3ISD9OutputArgEEEbPKNS_4TypeE
>>>> _ZNK4llvm18MipsTargetLowering6MipsCC8varArgFnEv
>>>>
>>>> _ZNK4llvm18MipsTargetLowering15LowerCallResultENS_7SDValueES1_NS_1
>>>> 1CallingConv2IDEbRKNS_15SmallVectorImplINS_3ISD8InputArgEEENS_5SDLo
>>>> cERNS_12SelectionDAGERNS4_IS1_EEPKNS_6SDNodeEPKNS_4TypeE
>>>>
>>>> _ZN4llvm18MipsTargetLowering6MipsCC19analyzeCallOperandsERKNS_15S
>>>> mallVectorImplINS_3ISD9OutputArgEEEbbPKNS_6SDNodeERSt6vectorINS_1
>>>> 4TargetLowering12ArgListEntryESaISD_EE
>>>>
>>>> _ZN4llvm18MipsTargetLowering6MipsCC22analyzeFormalArgumentsERKNS_
>>>> 15SmallVectorImplINS_3ISD8InputArgEEEbNS_14ilist_iteratorIKNS_8Argume
>>>> ntEEE
>>>>
>>>> _ZNK4llvm20MipsSETargetLowering33isEligibleForTailCallOptimizationERKNS_
>>>> 18MipsTargetLowering6MipsCCEjRKNS_16MipsFunctionInfoE
>>>> _ZN4llvm18MipsTargetLowering6MipsCCC2ENS_11CallingConv2IDEbbRNS_7
>>>> CCStateENS1_22SpecialCallingConvTypeE
>>>> _ZNK4llvm18MipsTargetLowering6MipsCC13numIntArgRegsEv
>>>>
>>>> _ZNK4llvm18MipsTargetLowering15writeVarArgRegsERSt6vectorINS_7SDVal
>>>> ueESaIS2_EERKNS0_6MipsCCES2_NS_5SDLocERNS_12SelectionDAGE
>>>> _ZNK4llvm18MipsTargetLowering21getSpecialCallingConvENS_7SDValueE
>>>>
>>>> _ZNK4llvm18MipsTargetLowering13copyByValRegsENS_7SDValueENS_5SDLo
>>>> cERSt6vectorIS1_SaIS1_EERNS_12SelectionDAGERKNS_3ISD10ArgFlagsTyERN
>>>> S_15SmallVectorImplIS1_EEPKNS_8ArgumentERKNS0_6MipsCCERKNS0_12B
>>>> yValArgInfoE
>>>> _ZNK4llvm18MipsTargetLowering6MipsCC17analyzeCallResultERKNS_15Small
>>>> VectorImplINS_3ISD8InputArgEEEbPKNS_6SDNodeEPKNS_4TypeE
>>>>
>>>> _ZNK4llvm20Mips16TargetLowering33isEligibleForTailCallOptimizationERKNS_
>>>> 18MipsTargetLowering6MipsCCEjRKNS_16MipsFunctionInfoE
>>>> _ZN4llvm18MipsTargetLowering6MipsCCC1ENS_11CallingConv2IDEbbRNS_7
>>>> CCStateENS1_22SpecialCallingConvTypeE
>>>>
>>>> -Tom
>>
>