Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add support to LLVM for alignment specification of memory objects #772

Closed
lattner opened this issue Jul 7, 2004 · 18 comments
Closed

Add support to LLVM for alignment specification of memory objects #772

lattner opened this issue Jul 7, 2004 · 18 comments
Labels
bugzilla Issues migrated from bugzilla enhancement Improving things as opposed to bug fixing, e.g. new or missing feature llvm:core

Comments

@lattner
Copy link
Collaborator

lattner commented Jul 7, 2004

Bugzilla Link 400
Resolution FIXED
Resolved on Feb 22, 2010 12:50
Version 1.0
OS All

Extended Description

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
@llvmbot
Copy link
Member

llvmbot commented Jul 7, 2004

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.

@lattner
Copy link
Collaborator Author

lattner commented Jul 7, 2004

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

@llvmbot
Copy link
Member

llvmbot commented Jul 7, 2004

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.

@lattner
Copy link
Collaborator Author

lattner commented Jul 7, 2004

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

@llvmbot
Copy link
Member

llvmbot commented Jul 7, 2004

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?

@lattner
Copy link
Collaborator Author

lattner commented Jul 7, 2004

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

@lattner
Copy link
Collaborator Author

lattner commented Dec 8, 2004

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

@lattner
Copy link
Collaborator Author

lattner commented Dec 8, 2006

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

@llvmbot
Copy link
Member

llvmbot commented Apr 1, 2007

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

@lattner
Copy link
Collaborator Author

lattner commented Apr 1, 2007

Sounds great to me!

@llvmbot
Copy link
Member

llvmbot commented Apr 1, 2007

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.

@llvmbot
Copy link
Member

llvmbot commented Apr 21, 2007

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

@lattner
Copy link
Collaborator Author

lattner commented Apr 21, 2007

great! should this be closed?

@llvmbot
Copy link
Member

llvmbot commented Apr 21, 2007

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).

@lattner
Copy link
Collaborator Author

lattner commented Apr 21, 2007

sounds right to me

@llvmbot
Copy link
Member

llvmbot commented Apr 21, 2007

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.

@llvmbot
Copy link
Member

llvmbot commented Apr 21, 2007

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...

@llvmbot
Copy link
Member

llvmbot commented Apr 23, 2007

The patches have been fixed and reapplied.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
@Endilll Endilll added enhancement Improving things as opposed to bug fixing, e.g. new or missing feature and removed new-feature labels Aug 15, 2023
pysuxing pushed a commit to pysuxing/llvm-project that referenced this issue Aug 14, 2024
@seven-mile
[CIR][CodeGen][NFC] Replace the calling convention in CodeGen with th…

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode
14aca60 
…e one in dialect (llvm#772)

This PR remove the header `CIR/CodeGen/CallingConv.h` and migrates all
`::cir::CallingConv` stuff to `::mlir::cir::CallingConv` in
`CIRGenTypes` and `CIRGenFunctionInfo`.

In TargetLowering library, LowerTypes and LowerFunctionInfo basically
have the same clangCallConvToLLVMCallConv stuff. The CC there is the
LLVM one. But those changes are not included because of the potential
conflicts. We can still easily switch to the dialect when it's needed.
keryell pushed a commit to keryell/llvm-project that referenced this issue Oct 19, 2024
@seven-mile @lanza
[CIR][CodeGen][NFC] Replace the calling convention in CodeGen with th…
8f08c82 
…e one in dialect (llvm#772)

This PR remove the header `CIR/CodeGen/CallingConv.h` and migrates all
`::cir::CallingConv` stuff to `::mlir::cir::CallingConv` in
`CIRGenTypes` and `CIRGenFunctionInfo`.

In TargetLowering library, LowerTypes and LowerFunctionInfo basically
have the same clangCallConvToLLVMCallConv stuff. The CC there is the
LLVM one. But those changes are not included because of the potential
conflicts. We can still easily switch to the dialect when it's needed.
searlmc1 pushed a commit to ROCm/llvm-project that referenced this issue Feb 22, 2025
@ronlieb
Manual update of LLVM_MAIN_REVISION to 528058 (llvm#772)

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode
f13ef07
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bugzilla Issues migrated from bugzilla enhancement Improving things as opposed to bug fixing, e.g. new or missing feature llvm:core
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@Endilll @lattner @llvmbot