llvm dev - Feb 2014 - [LLVMdev] [RFC] Removing FCA constants from the IR

Currently, you're allowed to form a constant of aggregate type using any
number of other constants you like. This makes scanning the instructions of
the IR needlessly complex when looking for references to constants.

There is no need to support this degree of complexity in the IR. We could
require that for anything but 'zeroinitializer' you cannot write a
constant
of aggregate (structure or array) type. You have to build it using
insertvalue.

Thoughts? This would simplify several things I'm working on currently, and
it is a super easy auto-upgrade and verifier addition.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140203/0cad91b4/attachment.html>

Bleh.

Well, just to add a grain of salt, doing this won't *actually* simplify
anything very much. The reality is that ConstantExpr's are much harder to
handle than FCA Constants. =/

So, maybe this would be a small step in that direction, but that's about it.


On Mon, Feb 3, 2014 at 1:24 AM, Chandler Carruth <chandlerc at
google.com>wrote:
> Currently, you're allowed to form a constant of aggregate type using
any
> number of other constants you like. This makes scanning the instructions of
> the IR needlessly complex when looking for references to constants.
>
> There is no need to support this degree of complexity in the IR. We could
> require that for anything but 'zeroinitializer' you cannot write a
constant
> of aggregate (structure or array) type. You have to build it using
> insertvalue.
>
> Thoughts? This would simplify several things I'm working on currently,
and
> it is a super easy auto-upgrade and verifier addition.
>
> -Chandler
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140203/f63e733f/attachment.html>

On 3 February 2014 09:24, Chandler Carruth <chandlerc at google.com>
wrote:
> Currently, you're allowed to form a constant of aggregate type using
any
> number of other constants you like. This makes scanning the instructions of
> the IR needlessly complex when looking for references to constants.
How would that work for VTables and such, which are global constants?

Tim.

On Mon, Feb 3, 2014 at 3:44 AM, Tim Northover <t.p.northover at
gmail.com>wrote:
> On 3 February 2014 09:24, Chandler Carruth <chandlerc at google.com>
wrote:
> > Currently, you're allowed to form a constant of aggregate type
using any
> > number of other constants you like. This makes scanning the
instructions
> of
> > the IR needlessly complex when looking for references to constants.
>
> How would that work for VTables and such, which are global constants?

I have no problems with aggregate constant initializers for global
variables. We can support the syntax without allowing them through the
verifier inside of function bodies.

My real problem lies with operands which are aggregate constant values.

As I said in my followup though, this problem is strictly smaller than the
constantexpr problem, and may not be worth addressing separately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140203/348957d4/attachment.html>

On Feb 3, 2014, at 2:07 AM, Chandler Carruth <chandlerc at google.com>
wrote:
> Bleh.
> 
> Well, just to add a grain of salt, doing this won't *actually* simplify
anything very much. The reality is that ConstantExpr's are much harder to
handle than FCA Constants. =/
> 
> So, maybe this would be a small step in that direction, but that's
about it.
I don’t see this as a good direction.  We still need the ability to initialize
global variables of FCA type.

If you’re interested in simplifying this space, I think that this would be a
much more fruitful direction:
http://llvm.org/bugs/show_bug.cgi?id=10368

Constant expressions that can trap don’t make sense, for example.

-Chris

On 2/3/14 1:24 AM, Chandler Carruth wrote:
> Currently, you're allowed to form a constant of aggregate type using 
> any number of other constants you like. This makes scanning the 
> instructions of the IR needlessly complex when looking for references 
> to constants.
>
> There is no need to support this degree of complexity in the IR. We 
> could require that for anything but 'zeroinitializer' you cannot
write
> a constant of aggregate (structure or array) type. You have to build 
> it using insertvalue.
>
> Thoughts? This would simplify several things I'm working on currently, 
> and it is a super easy auto-upgrade and verifier addition.
>
> -Chandler
What effect does this have on the readability of the IR?

Asking to make sure the point is considered, not because I neccessarily 
oppose your suggested change.  My main concern would have been for 
global variable initializers, but it sounds like you've revised your 
proposal to exclude those.

Philip