[llvm] r209007 - Fix most of PR10367.

[Rafael Espíndola]

Since I am the one that want to change, wouldn't it be better for me
to send the design email?

On 22 May 2014 19:42, Chandler Carruth <chandlerc at gmail.com> wrote:
> I feel like this entire discussion is somewhat pointless in its current
> form.
>
> I actually very much share John's concern about what the right general
> approach here is for LLVM's IR and it isn't 100% clear that what we have
> right now *is* the right solution. I'm actually quite dubious.
>
> The fact of the matter is that we haven't had any proper design discussion
> other than an old PR with limited audience attached. =/ That means the right
> set of eyes weren't on this issue for better or worse. What we have right
> now, AFAICT, *is* consistent with the express intent of the bug and the
> express tested usages of the feature in LLVM. I don't think we can do a good
> job of designing the right end-state abstraction without, well, a design.
> Including motivating use cases, examples, and test cases. Currently we don't
> have any of that.
>
> So, John, can you please propose how you thing aliases *should* work to
> llvmdev, with test cases and examples to motivate this? I like the design
> you seem to be aiming at, but frankly, I don't have nearly as good of design
> examples or test cases. You'll be able to make a better and more concrete
> proposal for how this *should* work.
>
> And then Rafael and you can argue about how to support specific operations
> (like RAUW) and figure out how best to support those.
>
> I'm moderately confident that we can easily auto-upgrade bitcode to and from
> all of these variants without trouble, so I don't see what's wrong leaving
> the current (very minimal and perhaps annoyingly un-featureful) design in
> tree until we have a reasonably agreed-upon design for something more

It is blocking the use offests.

Cheers,
Rafael