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

include/{Support,Config} -> include/llvm/{Support,Config} #724

Closed
llvmbot opened this issue May 29, 2004 · 5 comments
Closed

include/{Support,Config} -> include/llvm/{Support,Config} #724

llvmbot opened this issue May 29, 2004 · 5 comments
Labels
bugzilla Issues migrated from bugzilla code-cleanup

Comments

@llvmbot
Copy link
Member

llvmbot commented May 29, 2004

Bugzilla Link 352
Resolution FIXED
Resolved on Feb 22, 2010 12:55
Version 1.0
OS All
Reporter LLVM Bugzilla Contributor
CC @lattner

Extended Description

The include directory should contain exactly one directory: llvm.

All include/* directories need to be made into include/llvm/* directories.

The reason for this is so that llvm #includes (especally by users of LLVM)
cannot clash with any other software system. Right now we have header files in
include/Support and include/Config that could clash with header files from some
"Support" or "Config" application or module of an application.

After this change is made, including any LLVM header will have the form:

#include <llvm/MODULE/HEADER.h>
@llvmbot
Copy link
Member Author

llvmbot commented May 29, 2004

*** Bug #555 has been marked as a duplicate of this bug. ***

@llvmbot
Copy link
Member Author

llvmbot commented Sep 1, 2004

Script to do the cvs repository modifications
Review and run this script against the LLVM cvs repository in order to make
copies of ,v files for headers moved to new locations. This needs to be done
before I can commit the file modifications.

@llvmbot
Copy link
Member Author

llvmbot commented Sep 1, 2004

The attachment needs to be run so I can commit changes.

Note that the resolution to this bug will also encapsulate the movement of
abstract data types from include/Support to include/llvm/ADT, as noted in bug 351.

@llvmbot
Copy link
Member Author

llvmbot commented Sep 1, 2004

One more thing to be done before resolving this:

Split the abstract data type implementations out of lib/Support and into
lib/ADT. This will also require a new library to be linked with in the various
tools.

Either that or rename libsupport.a libsupport+adt.a

@llvmbot
Copy link
Member Author

llvmbot commented Sep 2, 2004

This change has been implemented. All public header files are now in
include/llvm. The change set is too big to list here but it begins with:

http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040830/017770.html

and ends with:

http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040830/017837.html

Yes, changes in 67 directories :)

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
pysuxing pushed a commit to pysuxing/llvm-project that referenced this issue Aug 14, 2024
@seven-mile
[CIR][CodeGen][LowerToLLVM] End-to-end implementation of offload_* …

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode
9445acc 
…cases for OpenCL with SPIR-V target (llvm#724)

This PR implements `offload_*` cases discussed in [this
thread](https://discourse.llvm.org/t/rfc-clangir-unified-address-space-design-in-clangir/79728).

* Integrate target-specific CIR-to-LLVM address space map into
`TargetLoweringInfo`
* CIRGen: Implement these cases in `getValueFromLangAS`
* Lowering: Extend the state of type converter with `LowerModule`

When frontend provides a new LangAS like `opencl_generic`, it would be
processed by CIRGenTypes and `Builder.getPointerTo()` and encoded as
`offload_generic`.

When we lower CIR to LLVM, 

* For pointer types without address space attribute, it's mapped to `ptr
addrspace(0)` directly
* For target cases `target<x>`, it's mapped to `ptr addrspace(x)`
* For other defined cases, query the target info with a new virtual
method `getTargetAddrSpaceFromCIRAddrSpace`. General targets like X86
and ARM64 map all known cases to 0. For SPIR-V target here, it maps
`offload_generic` to `addrspace(4)`.
keryell pushed a commit to keryell/llvm-project that referenced this issue Oct 19, 2024
@seven-mile @lanza
[CIR][CodeGen][LowerToLLVM] End-to-end implementation of offload_* …
491ab40 
…cases for OpenCL with SPIR-V target (llvm#724)

This PR implements `offload_*` cases discussed in [this
thread](https://discourse.llvm.org/t/rfc-clangir-unified-address-space-design-in-clangir/79728).

* Integrate target-specific CIR-to-LLVM address space map into
`TargetLoweringInfo`
* CIRGen: Implement these cases in `getValueFromLangAS`
* Lowering: Extend the state of type converter with `LowerModule`

When frontend provides a new LangAS like `opencl_generic`, it would be
processed by CIRGenTypes and `Builder.getPointerTo()` and encoded as
`offload_generic`.

When we lower CIR to LLVM,

* For pointer types without address space attribute, it's mapped to `ptr
addrspace(0)` directly
* For target cases `target<x>`, it's mapped to `ptr addrspace(x)`
* For other defined cases, query the target info with a new virtual
method `getTargetAddrSpaceFromCIRAddrSpace`. General targets like X86
and ARM64 map all known cases to 0. For SPIR-V target here, it maps
`offload_generic` to `addrspace(4)`.
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 code-cleanup
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@llvmbot