Also, the alloca and malloc instructions should take an optional alignment
argument, and GlobalValues should allow an explicit alignment constraint to be set.

For malloc, this allows us to represent valloc and memalign directly
in LLVM.  For alloca, it allows us to support the alignment attributes in the
GCC front-end directly.  Global variables should also be extended to support
alignment attributes.  This will be required for vectorization work.

If an alignment is specified as zero, the default, then that means we should
follow the target alignment settings.  This should be _by far_ the most common
setting, so we should not even bother encoding this argument into the bytecode
file unless it is nonzero.

This was originally a comment in Bug 122, but it should be it's own bug, so I'm
splitting it out.

-Chris

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.