[llvm] r209007 - Fix most of PR10367.

[Chandler Carruth]

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 complex?

-Chandler


On Mon, May 19, 2014 at 11:42 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> > I don’t think it’s a bad practice to open bugs with design issues, I
> just think
> > that you should not treat that as a substitute for a detailed proposal
> sent
> > to llvm-dev.  Including a link to the PR saying “we’ve talked about it a
> lot
> > here” is fine.  Telling me that, in order to have an opinion on IR
> design,
> > I need to keep up with llvm-commits, the entire bug tracker, and your
> personal
> > discussions with Chris at the developers’ conference is not okay.
>
> I keep to saying that in the years this has been up you should have
> been able to noticed it and that is a reasonable expectation.
>
> It also seems you are holding me to a higher standard than yourself.
> If you started to use a feature that we could not ever stream
> correctly via bitcode and we have a bug about dropping. It seems you
> are the one that would have the much higher burden of proposing a
> change: geps with non zero offsets.
>
> > Here's an obvious one: a global alias to a ConstantInt (maybe
> inttoptr’ed)
> > is a really natural way to express an absolute symbol.
>
> Or an offset from null. I quiet like the feature. I will try to come
> up with a patch for it once the current one is done.
>
> Cheers,
> Rafael
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140522/1b73dc31/attachment.html>