search for: lp64d

...getImpl and do some hack in backend[2]. 1. https://reviews.llvm.org/D72245#change-sHyISc6hOqcy (see llc.cpp) 2. https://reviews.llvm.org/D72246 (see RISCVAsmBackend.h) I think [1] and [2] are not good enough, the other ideals like 3. encode target abi info in triple name. ex. riscv64-unknown-elf-lp64d 4. encode target-abi into in target-feature (maybe it's not a good ideal because mips reverted this approach before. http://llvm.org/viewvc/llvm-project?view=revision&revision=227583) 5. users should pass target-abi themselves. (append -Wl,-plugin-opt=-target-abi=ipl32f when compiling with...

...o link. I'm not particularly familiar with LTO but going by the description of the problem it seems to me that the overall issue is that for 1, 2, and 5, each module fails to completely describe the contents. They each have a label saying it's riscv64, elf, etc. but it doesn't mention lp64d anywhere. As a result you can't check that you aren't trying to mix incompatible modules and can only trust (and require) the command line option. It's worth mentioning that DataLayout tends to change for different ABI's so the ABI is kind-of there but there isn't anything that...

...https://reviews.llvm.org/D72245#change-sHyISc6hOqcy (see llc.cpp) >> 2. https://reviews.llvm.org/D72246 (see RISCVAsmBackend.h) >> >> I think [1] and [2] are not good enough, the other ideals like >> >> 3. encode target abi info in triple name. ex. riscv64-unknown-elf-lp64d >> 4. encode target-abi into in target-feature (maybe it's not a good ideal >> because mips reverted this approach >> before. http://llvm.org/viewvc/llvm-project?view=revision&revision=227583 >> ) >> >> 5. users should pass target-abi themselves. (append...

...cularly familiar with LTO but going by the description of >> the problem it seems to me that the overall issue is that for 1, 2, and 5, >> each module fails to completely describe the contents. They each have a >> label saying it's riscv64, elf, etc. but it doesn't mention lp64d anywhere. >> As a result you can't check that you aren't trying to mix incompatible >> modules and can only trust (and require) the command line option. It's >> worth mentioning that DataLayout tends to change for different ABI's so the >> ABI is kind-of ther...

...D72245#change-sHyISc6hOqcy> (see llc.cpp) > 2. https://reviews.llvm.org/D72246 <https://reviews.llvm.org/D72246> (see RISCVAsmBackend.h) > > I think [1] and [2] are not good enough, the other ideals like > > 3. encode target abi info in triple name. ex. riscv64-unknown-elf-lp64d > 4. encode target-abi into in target-feature (maybe it's not a good ideal because mips reverted this approach > before. http://llvm.org/viewvc/llvm-project?view=revision&revision=227583 <http://llvm.org/viewvc/llvm-project?view=revision&revision=227583>) > > 5. user...

...O but going by the description of >>>> the problem it seems to me that the overall issue is that for 1, 2, and 5, >>>> each module fails to completely describe the contents. They each have a >>>> label saying it's riscv64, elf, etc. but it doesn't mention lp64d anywhere. >>>> As a result you can't check that you aren't trying to mix incompatible >>>> modules and can only trust (and require) the command line option. It's >>>> worth mentioning that DataLayout tends to change for different ABI's so the >...

...gt; > I'm not particularly familiar with LTO but going by the description of the problem it seems to me that the overall issue is that for 1, 2, and 5, each module fails to completely describe the contents. They each have a label saying it's riscv64, elf, etc. but it doesn't mention lp64d anywhere. As a result you can't check that you aren't trying to mix incompatible modules and can only trust (and require) the command line option. It's worth mentioning that DataLayout tends to change for different ABI's so the ABI is kind-of there but there isn't anything that...

...cularly familiar with LTO but going by the description of >> the problem it seems to me that the overall issue is that for 1, 2, and 5, >> each module fails to completely describe the contents. They each have a >> label saying it's riscv64, elf, etc. but it doesn't mention lp64d anywhere. >> As a result you can't check that you aren't trying to mix incompatible >> modules and can only trust (and require) the command line option. It's >> worth mentioning that DataLayout tends to change for different ABI's so the >> ABI is kind-of ther...

...O but going by the description >>>> of the problem it seems to me that the overall issue is that for 1, 2, and >>>> 5, each module fails to completely describe the contents. They each have a >>>> label saying it's riscv64, elf, etc. but it doesn't mention lp64d anywhere. >>>> As a result you can't check that you aren't trying to mix incompatible >>>> modules and can only trust (and require) the command line option. It's >>>> worth mentioning that DataLayout tends to change for different ABI's so the >...

...;m not particularly familiar with LTO but going by the description of > the problem it seems to me that the overall issue is that for 1, 2, and 5, > each module fails to completely describe the contents. They each have a > label saying it's riscv64, elf, etc. but it doesn't mention lp64d anywhere. > As a result you can't check that you aren't trying to mix incompatible > modules and can only trust (and require) the command line option. It's > worth mentioning that DataLayout tends to change for different ABI's so the > ABI is kind-of there but there isn&...

...liar with LTO but going by the description >>> of the problem it seems to me that the overall issue is that for 1, 2, and >>> 5, each module fails to completely describe the contents. They each have a >>> label saying it's riscv64, elf, etc. but it doesn't mention lp64d anywhere. >>> As a result you can't check that you aren't trying to mix incompatible >>> modules and can only trust (and require) the command line option. It's >>> worth mentioning that DataLayout tends to change for different ABI's so the >>> ABI...

Hello everyone, 9.0.0-rc6 was just tagged from the release_90 branch at r372100. In the Git monorepo, it's tagged as llvmorg-9.0.0-rc6. Source code and docs are available at https://prereleases.llvm.org/9.0.0/#rc6 This is the same as rc5 plus one very minor change (r371969) that still seemed good to pick up. I'm not allocating extra time for testing this one, expecting to tag

Hello everyone, 9.0.0-rc2 was tagged yesterday from the release_90 branch at r368683. In the Git monorepo it's available as the llvmorg-9.0.0-rc2 tag. Source code and docs are available at https://prereleases.llvm.org/9.0.0/#rc2 Binaries will be added as they become available. The tag went in roughly one week behind schedule (see "Upcoming Releases" at https://llvm.org), but