llvm dev - Jan 2016 - Functions have two types, one can be mutated but not the other

Function has its own FunctionType* member as well as a Type* member that it
inherits from GlobalValue. The latter can be mutated but not the former, leading
to potential strange inconsistencies.

While I realize using mutateType is probably going to trigger a bunch of
"you're doing it wrong" replies, it seems like mutateType, as a
necessary evil, should be virtual and do the right wrong thing for Functions
too.

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151124/1d42aeff/attachment.html>

Correction: there are 3 Type * members - one on Function, one on GlobalValue,
and one on Value. The last is mutable, but not the other two.

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Andy
Ayers via llvm-dev
Sent: Tuesday, November 24, 2015 9:26 AM
To: llvm-dev at lists.llvm.org
Subject: [llvm-dev] Functions have two types, one can be mutated but not the
other

Function has its own FunctionType* member as well as a Type* member that it
inherits from GlobalValue. The latter can be mutated but not the former, leading
to potential strange inconsistencies.

While I realize using mutateType is probably going to trigger a bunch of
"you're doing it wrong" replies, it seems like mutateType, as a
necessary evil, should be virtual and do the right wrong thing for Functions
too.

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151124/b7605b45/attachment.html>

On Tue, Nov 24, 2015 at 9:25 AM, Andy Ayers via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Function has its own FunctionType* member as well as a Type* member that
> it inherits from GlobalValue. The latter can be mutated but not the former,
> leading to potential strange inconsistencies.
>
>
>
> While I realize using mutateType is probably going to trigger a bunch of
> “you’re doing it wrong” replies, it seems like mutateType, as a necessary
> evil, should be virtual and do the right wrong thing for Functions too.
>
>
>
> Thoughts?
>
I've been perpetrating some of this for the typeless/opaque pointer IR
stuff (some details here: https://www.youtube.com/watch?v=OWgWDx_gB1I - or
on a few threads on llvm-dev).

I got rid of that extra one in Function - thanks for noticing.

If I recall correctly, even before my work, it wasn't possible to rely
solely on mutateType of the operands  so various special cases have been
added (ValueMapper.cpp is a good example of some of these special cases)

I'm not sure why those issues might not have come up when dealing with
Globals. Perhaps you have some examples (eg: linking bitcode with globals -
where the value type gets out of sync with the pointer type? Maybe if we
add some more assertions in to check the two values are in sync we'd find
cases where they've gotten out of sync?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160119/eeaff078/attachment.html>

Thanks. Our use case is pretty simple:

Create a function with some placeholder type.
Figure out the actual function type and create some IR that calls the function
with that type. Update function’s type via mutateType.
Dump the module. The function’s “declaration” still shows it has the placeholder
type.
This doesn’t cause us any problems because the IR is what matters and it’s got
the right description.

FWIW we do this because the transformation from an MSIL signature to an
ABI-level signature is somewhat involved, and we’ve intertwined the code to
generate the right call sequence with the code that figures out what type you
end up with once you’ve done all the various transformations, so to start things
off, we need a way to refer to the function without knowing precisely what type
it will end up with.

From: David Blaikie [mailto:dblaikie at gmail.com]
Sent: Tuesday, January 19, 2016 3:36 PM
To: Andy Ayers <andya at microsoft.com>
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Functions have two types, one can be mutated but not the
other



On Tue, Nov 24, 2015 at 9:25 AM, Andy Ayers via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Function has its own FunctionType* member as well as a Type* member that it
inherits from GlobalValue. The latter can be mutated but not the former, leading
to potential strange inconsistencies.

While I realize using mutateType is probably going to trigger a bunch of “you’re
doing it wrong” replies, it seems like mutateType, as a necessary evil, should
be virtual and do the right wrong thing for Functions too.

Thoughts?

I've been perpetrating some of this for the typeless/opaque pointer IR stuff
(some details here:
https://www.youtube.com/watch?v=OWgWDx_gB1I<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.youtube.com%2fwatch%3fv%3dOWgWDx_gB1I&data=01%7c01%7candya%40microsoft.com%7c692fcbd2bdf147a7a2fb08d321293eef%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=VWuobdaqbGrRzX0N7VrZw6UubBarZThFRpTl9aoe%2fFc%3d>
- or on a few threads on llvm-dev).

I got rid of that extra one in Function - thanks for noticing.

If I recall correctly, even before my work, it wasn't possible to rely
solely on mutateType of the operands  so various special cases have been added
(ValueMapper.cpp is a good example of some of these special cases)

I'm not sure why those issues might not have come up when dealing with
Globals. Perhaps you have some examples (eg: linking bitcode with globals -
where the value type gets out of sync with the pointer type? Maybe if we add
some more assertions in to check the two values are in sync we'd find cases
where they've gotten out of sync?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160120/dceb1d41/attachment.html>