[llvm] r209007 - Fix most of PR10367.

[Rafael Espíndola]

> 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)

That is part of the type.

>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 is not a substantial part. There is a *lot* more in ConstantExpr.
As an extreme example, ConstantExpr can trap.

> 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…

So it is better to have a more restrictive representation. It would be
better to completely redesign ConstantExpr to be something that ends
up being an actual constant in most cases. That is a *far* bigger
change, but once it is done we can reevaluate what should and should
not be a ConstantExpr. For now we can at least have one area where
what we represent in IR actually matches what is possible.

> John.

Cheers,
Rafael