[llvm] r209007 - Fix most of PR10367.

[John McCall]

On May 17, 2014, at 7:54 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>> 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.

1. That is clearly a mistake.

2. You are not going to be able to fix that mistake with a change in
representation.  In general, the operands of a trapping operation are
otherwise legal constants, so the only way to intrinsically remove the
potential for trapping constants is to remove all operations from
ConstantExpr that could possibly trap on any operand.  I don’t think
you have community support for that, so assuming that that’s the
inevitable direction is not actually reasonable.

3. There is a much more obvious solution: we should just document
that ConstantExprs which are guaranteed to trap are illegal, and then
check that in the verifier.  Constant propagation should already be
doing this analysis to decide that it can safely turn an instruction
into a constant.

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

I don’t see why.  Your more restrictive representation is just going to
arbitrarily limit the ability of frontends and backends to achieve things
that your representation doesn’t realize are possible.  LLVM IR should
not be in the business of knowing what common object file formats
are capable of expressing.

John.