llvm dev - Aug 2020 - [RFC][LLVM] New Constant type for representing function PLT entries

On 8/21/20 1:34 AM, Renato Golin via llvm-dev wrote:
> +1 to Eric's point. We could get into a state where we must get the 
> relocation right in the IR to get a good (or worse, any) lowering.
>
> I'd rather have a canonical representation, relocation friendly, that 
> we try to keep and back ends know how to lower well.
>
> --renato

FWIW, I think that we all agree to that. I don't see that what's being 
proposed changes this general philosophy. The general problem is: what 
happens when that lowering has multiple good options, and the ABI 
requires particular choices under certain circumstances?

Thanks again,

Hal

>
> On Fri, 21 Aug 2020, 04:35 Eric Christopher via llvm-dev, 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>
>     I do have concerns about the amount of object level modeling that
>     we want to do in the IR though. While it isn't the highest level
>     IR we've managed to mostly avoid these kinds of
>     features/complications in the past. I'm definitely interested in
>     hearing some alternate implementations here and there rather than
>     a full set of constants for relocations. Keeping the IR abstract
>     enough over the object file level other than in generalizable
>     cases still feels like a win.
>
>     -eric
>
>     On Thu, Aug 20, 2020 at 8:44 PM Chris Lattner via llvm-dev
>     <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>
>         Hi Leonard,
>
>         I haven’t looked at your patch in detail, but I think that
>         this is a step in the right direction.  I would like to see
>         new “Constant*”’s that directly map onto the relocations that
>         various object formats use (for example, macho has a
>         relocation for “&g1-&g2+cst”).  This would get us to a more
>         principled lowering in many cases as well as make the backend
>         modeling more specific.
>
>         -Chris
>
>>         On Aug 20, 2020, at 11:29 AM, Leonard Chan via llvm-dev
>>         <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>>
>>         Hi all,
>>
>>         We would like to propose a new Constant type in LLVM for
>>         representing entries in the Procedure Linkage Table (PLT).
>>
>>         The PLT is a data structure used for dispatching
>>         position-independent function calls to appropriate functions
>>         where the address of the function is not known statically.
>>         Right now, if a call is made to a function, it may be lowered
>>         to a direct call to the function itself or the PLT entry for
>>         that function. LLVM has checks that dictate if the function
>>         call should be a direct reference or PLT entry, but we don’t
>>         have a way in IR to semantically represent that the PLT entry
>>         should be used.
>>
>>         The proposed constant would be analogous to BlockAddress, but
>>         instead represent the PLT entry for functions. The usage
>>         could look something like:
>>
>>         pltentry(@function)
>>
>>         and would always have the same type as the function. A
>>         pltentrywould operate exactly like a function, but the main
>>         difference is that it’s lowered to the PLT entry
>>         (function at plt) on targets that support PLT relocations. The
>>         linker can then decide if it should be relaxed into a direct
>>         reference or remain a PLT entry.
>>
>>         I have a very rough WIP implementation at
>>         https://reviews.llvm.org/D77248
>>         <https://reviews.llvm.org/D77248>.
>>
>>         Thoughts and opinions?
>>
>>         Thanks,
>>         Leonard
>>
>>         _______________________________________________
>>         LLVM Developers mailing list
>>         llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>         https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>        
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
>         _______________________________________________
>         LLVM Developers mailing list
>         llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>         https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>         <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200821/6d5d3154/attachment.html>

On Fri, 21 Aug 2020 at 16:20, Hal Finkel <hfinkel at anl.gov> wrote:
> FWIW, I think that we all agree to that. I don't see that what's
being
> proposed changes this general philosophy. The general problem is: what
> happens when that lowering has multiple good options, and the ABI requires
> particular choices under certain circumstances?
>
If this is decided from the front-end and needs to survive all the way to
the back-end, why not just add a generic function attribute?

Perhaps I'm interpreting this the wrong way, but adding a special
(independent) entry to the IR that hints at an ABI correctness seems
fragile to me.

--reanto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200821/44d0b64b/attachment-0001.html>

On 8/21/20 10:39 AM, Renato Golin wrote:
> On Fri, 21 Aug 2020 at 16:20, Hal Finkel <hfinkel at anl.gov 
> <mailto:hfinkel at anl.gov>> wrote:
>
>     FWIW, I think that we all agree to that. I don't see that
what's
>     being proposed changes this general philosophy. The general
>     problem is: what happens when that lowering has multiple good
>     options, and the ABI requires particular choices under certain
>     circumstances?
>
>
> If this is decided from the front-end and needs to survive all the way 
> to the back-end, why not just add a generic function attribute?

But it's not a property of the functions, as I understand it, it's a 
function of place where the function is referenced. In this case, maybe 
we could consider it a property of the vtable itself, and some attribute 
on the array/global would work?

>
> Perhaps I'm interpreting this the wrong way, but adding a special 
> (independent) entry to the IR that hints at an ABI correctness seems 
> fragile to me.

This is a first-class IR entity. It seems the opposite of fragile. The 
interesting question is going to be: do we have a wile bunch of other 
code that generally handles constant expressions that needs to learn 
about this new kind of function reference?

  -Hal

>
> --reanto
>
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200821/4dd2df63/attachment.html>