[llvm-dev] How to force unused external routine declaration into object

[John Reagan via llvm-dev]

I had thought about "used", but not aware of the @llvm.used, et al.

I wrote some test programs with __attribute__((used)) but that felt like
something you'd put on function definitions to force code to be
generated regardless.

In the worst case, I'll do some metadata hack (I've ready had to do that
for BLISS' GLOBAL BIND feature).

Thanks for the response.  I'll let folks know what I find out.

P.S. we're about to enter field test for OpenVMS after 2+ years of work
on the system and compilers.  I can now boot it under VBox on my W10
system here at home.

On 5/7/2020 4:16 PM, Robinson, Paul wrote:
> 
> 
>> -----Original Message-----
>> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of John Reagan
>> via llvm-dev
>> Sent: Wednesday, May 6, 2020 9:29 PM
>> To: via llvm-dev <llvm-dev at lists.llvm.org>
>> Subject: [llvm-dev] How to force unused external routine declaration into
>> object
>>
>> I'm defining an external function in the IR that has no uses at all.  No
>> calls, no address taken, nada.
>>
>> Such an unused declaration seems to be just dropped on the floor as not
>> needed.  Seems reasonable in most cases.
>>
>> However, one of my OpenVMS compilers (BLISS) has a language rule that
>> expects such definitions to get into the ELF symbol table as a way to
>> compel the linker to include certain object modules.
>>
>> With our backend for our older targets, we had a "required_om_entry"
>> function attribute that told our backend to put it out regardless.
>>
>> I was looking at the list of function attributes and don't see anything
>> that would accomplish this.
>>
>> I could just create a bogus variable and initialize it with the
>> function's value, but that seems unsavory.
>>
>> I'm still using a way old version but I'll adapt as needed.
>>
>> Any suggestions?  Did I miss something?
> 
> Hi John,
> 
> This sounds like __attribute__((used)) which Clang turns into
> entries in the @llvm.used list.  There's also @llvm.compiler.used
> and I'm not clear what the difference is, but hopefully that's
> enough of a pointer that you can get it to work for Bliss.
> 
> --paulr
> 
>>
>> John (safely at home with sufficient food & wine)
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev