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.