I smell more bytecode changes coming ... :)

Instead of continuing to modify the bytecode format piecemeal, lets acknowledge
that may be future requirements coming down the line and reserve some bits/bytes
for various flags now as we make this adjustment.

I'd like to see comments on what bytecode formats are needed to support this bug.

For the instructions, it shouldn't require any changes: we'll just encode 1
argument for default-alignment case, and 2 for the non-default-alignment case.

Setting an alignment on a global var/function will require more info: We will
need one bit to say that an alignment is set. If you'd like to reserve space
for this in the format, please go ahead! :)

-Chris

Okay, so the bit in the global vars steals away from the maximum number of types
in a module (see bug 392). I think we should just define types as being 24 bit
quantities (16 million in a module) and be done with it. The extra bits we get
elsewhere will be reserved for future use. What do you think?

Reid.

Sounds good to me. Define all ones as an extension field (if it's set, there is
a separate vpr after it for types that are bigger than 2^24) and we're set.

-Chris

I'm not grokking this:

Define all ones as an extension field

What "ones" ?

(if it's set, there is a separate vpr after it for types
that are bigger than 2^24) and we're set.

What's a vpr?

Define all ones as an extension field
What "ones" ?

Sorry. If the type is ((2^24)-1) (all 24 1's), it should be an extension field.

What's a vpr?

a benchmark. I meant to type vbr :)

-chris

A note: when this PR is implemented, this patch should be reverted:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041206/021846.html

-Chris

alignment support has been added to globals, functions and allocations. It is currently missing from load/
store.

The assembly format for alignment attributes on load/stores will be an optional
comma delimited alignment parameter at the end of the instruction,
such as:

%tmp5 = load i32* %tmp4, align 4
store i32 %val, i32* %tmp3, align 4

Sounds great to me!

The bytecode representation for aligned loads and stores will use pseudo ops for 'attributed' load/store
instructions. These instructions contain a set of optional attributes encoded in some (yet to be
determined) way. The current volatile load/store instructions will be subsumed by
these instructions.

Support for align attributes on load/store instructions has been added.

great! should this be closed?

I'll assume that by 'add support to LLVM' in the bug title it means add to the LLVM language and
framework, in which case I think this bug is closed. The front end and back ends probably still need to be
updated to use this info, though those could be under different PR(s).

sounds right to me

It appears that vector loads don't currently have a subclass of SDNode, which is where alignment
information for other loads/stores is kept. This will need to be fixed.

Hmm. Upon further inspection, it appears that ISD::VLOAD gets lowered later in legalization of the DAG,
so perhaps this is not a problem after all...

The patches have been fixed and reapplied.