[llvm] r209007 - Fix most of PR10367.

[John McCall]

On May 17, 2014, at 4:22 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>> I’m sorry that I didn’t see your patch before you committed.  Can you explain
>> what benefits this has over allowing a (restricted) ConstantExpr in the
>> aliasee?
>> 
>> My understanding is that Chris has changed his mind since he originally
>> filed PR10367.  It certainly seems to me that, if we’re going to support
>> non-zero offsets and addrspace conversions and so on in aliases, it’s
>> far better to allow a restricted restricted set of constant expressions than
>> it is to awkwardly replicate all of that functionality specifically for
>> GlobalAlias.
> 
> The benefit is that ContantExpr is far more general than what is
> needed. Simply allowing two different types covers all the uses that
> were working on trunk. The missing feature is offsets.

That argument works when it’s really just “allowing two different types”, but it breaks down the more features you add to aliases.  If aliases support bitcasts (by just allowing the type to be different) and geps (by allowing an offset to be given) and address-space conversions (by allowing an explicit address space that doesn’t match the base) then it sure sounds to me like you’re just repeating a substantial subset of expressive capability of ConstantExpr, and there isn’t a huge benefit to this approach over just semantically restricting what can appear in an alias.

It also seems to me like the set of expressions supported by global aliases is only likely to increase.  It’s a pretty natural way to express absolute symbols, for example.

Note that there are already practical restrictions on the kinds of ConstantExpr that can appear in various places — e.g. you can make a ConstantExpr that divides the address of a global variable by 7, but there aren’t any relocations that support that, so…

John.