[PATCH] Implement function prefix data as an IR feature.

[Peter Collingbourne]

On Mon, Jul 29, 2013 at 10:20:44PM +0200, Duncan Sands wrote:
> Hi Reid,
>
> On 29/07/13 19:39, Reid Kleckner wrote:
>> On Mon, Jul 29, 2013 at 5:44 AM, Duncan Sands <duncan.sands at gmail.com
>> <mailto:duncan.sands at gmail.com>> wrote:
>>
>>     Hi Peter,
>>
>>     On 26/07/13 22:57, Peter Collingbourne wrote:
>>
>>         Ping?
>>
>>
>>     I think requiring the prefix data to start with a bunch of machine specific
>>     magic bytes is really horrible.

It's ugly, but I don't think it's that bad.  It's just an encoding
of a sequence of instructions, the format of which is pretty much
fixed for each target.  It's roughly a one-to-one correspondence with
something like inline asm, with the advantage that we can easily do
things like optimise away constant loads.

Besides, I think the alternatives presented so far are worse in that
they don't give the frontend enough freedom or introduce unnecessary
implementation complexity.

>> Why can't codegen insert the magic code
>>     sequence automatically?  I don't think this patch should go in as it is.

This presupposes that we know what the magic code sequence is going
to be.  I'm imagining a lightweight function marker consisting
of a few variations of 'nop' that an implementation might use to
(e.g.) mark certain functions as requiring special runtime support.

>> The user will have to know the size of the magic code sequence somehow.
>
> for example, by calling an intrinsic introduced for this purpose, that codegen
> lowers to the appropriate number.

I don't like the idea of using an intrinsic for this.  For one thing,
it cannot be used in a constant.  Also, what about versioning?
We would essentially be forced to preserve sequence length and (if
we want the frontend to be able to distinguish metadata-present and
metadata-absent functions) the format of the code sequence in order
to maintain compatibility in dependent projects.  Whereas with my
proposal compatibility decisions can be made by the frontend.

As I explained before:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063949.html
I would prefer to have target-independent support in a layer above
the target-dependent support in IR.  I also think having codegen
insert the code sequence automatically (if desired by the frontend)
can be done incrementally on top of this work.

Thanks,
-- 
Peter