new LLVM IR features

Hello,

I've recently made a number of LLVM IR langauge changes, and I'm
sending this message out to let people know about them and to
ask for feedback. They're backwards-compatible, so this shouldn't
require any front-end changes. llvm.org/docs/LangRef.html is
updated to describe these changes, so you can read all about them
there. Here's a quick summary of the changes:

Integer add, sub, and mul now have two optional flags: nuw and nsw,
which are "No Unsigned Wrap" and "No Signed Wrap", respectively.
With these flags, the result value of the operator is undefined
if wrapping of the specified variety occurs.

Getelementptr now has an optional flag: inbounds. WIth this flag,
if the result of a getelementptr is not in bounds of an allocated object,
the result value is undefined. Note the the new getelementptr rule
applies regardless of whether the keyword is present.

And, I've added a new section on "Pointer Aliasing Rules", which
contains the rules described in by "proposed new rule for getelementptr"
message, with various fixes from the resulting discussion.

Comments, suggestions, corrections are welcome.

Should inbounds be on by default? If clang and llvm-gcc will be setting
it for normal pointer arithmetic, it will make the assembly output more
cluttered. On the other hand, having it be off by default is consistent
with nuw and nsw, which are off by default. And it's a nice property
that the default behavior of the operator is more permissive, with an
"opt-in" option to allow more aggressive optimization, rather than the
other way around. But I'm open to suggestions.

Dan

How do the semantics of "inbounds" differ from the new GEP rules?

                            -Dave

In summary:

The new GEP rule says that you can't dereference a pointer within an
object if it was computed from a GEP based on a different object.

The optional inbounds flag further constrains a GEP by saying that
the integer arithmetic implied by a GEP won't overflow.

Dan

The new GEP rule says that you can't dereference a pointer within an
object if it was computed from a GEP based on a different object.

Ok.

The optional inbounds flag further constrains a GEP by saying that
the integer arithmetic implied by a GEP won't overflow.

Then maybe it should be renamed. As I understand this, I could compute
an overflowing GEP so that the end result os an address that is within the
bounds of the object. That's still "in bounds" but is not "inbounds."

                                 -Dave

Aha, good catch! I'll rename the keyword and reword the documentation
in terms of integer overflow.

Dan