search for: codegenopt

Displaying 15 results from an estimated 15 matches for "codegenopt".

2018 Apr 04
2
[RFC] Adding function attributes to represent codegen optimization level
On Tue, Apr 3, 2018 at 12:47 PM via llvm-dev <llvm-dev at lists.llvm.org> wrote: > All, > A recent commit, D43040/r324557, changed the behavior of the gold plugin > when compiling with LTO. The change now causes the codegen optimization > level to default to CodeGenOpt::Default (i.e., -O2) rather than use the > LTO optimization level. The argument was made that the LTO optimization > level should control the amount of cross-module optimizations done by > LTO, but it should not control the codegen optimization level; that > should be based off of the...
2017 Aug 22
2
Subtarget Initialization in <ARCH>TargetMachine constructor
...StringRef CPU, StringRef FS, const TargetOptions &Options, Optional<Reloc::Model> RM, Optional<CodeModel::Model> CM, CodeGenOpt::Level OL, bool JIT) : LLVMTargetMachine(T, computeDataLayout(TT), TT, CPU, FS, Options, getEffectiveRelocModel(RM), getEffectiveCodeModel(CM), OL), TLOF(make_unique<TargetLoweringObjectFileELF>()), Subtarget(TT, CPU, FS, *this)...
2018 Apr 09
1
[RFC] Adding function attributes to represent codegen optimization level
...;> écrit : >>> >>> All, >>>> A recent commit, D43040/r324557, changed the behavior of the gold >>>> plugin >>>> when compiling with LTO. The change now causes the codegen >>>> optimization >>>> level to default to CodeGenOpt::Default (i.e., -O2) rather than use >>>> the >>>> LTO optimization level. The argument was made that the LTO >>>> optimization >>>> level should control the amount of cross-module optimizations done >>>> by >>>> LTO, but it s...
2018 Apr 06
2
[RFC] Adding function attributes to represent codegen optimization level
...at lists.llvm.org> a >> écrit : >> >> All, >>> A recent commit, D43040/r324557, changed the behavior of the gold >>> plugin >>> when compiling with LTO. The change now causes the codegen >>> optimization >>> level to default to CodeGenOpt::Default (i.e., -O2) rather than use >>> the >>> LTO optimization level. The argument was made that the LTO >>> optimization >>> level should control the amount of cross-module optimizations done >>> by >>> LTO, but it should not control the co...
2018 Apr 05
1
[RFC] Adding function attributes to represent codegen optimization level
..., via llvm-dev <llvm-dev at lists.llvm.org> a > écrit : > >> All, >> A recent commit, D43040/r324557, changed the behavior of the gold >> plugin >> when compiling with LTO. The change now causes the codegen >> optimization >> level to default to CodeGenOpt::Default (i.e., -O2) rather than use >> the >> LTO optimization level. The argument was made that the LTO >> optimization >> level should control the amount of cross-module optimizations done >> by >> LTO, but it should not control the codegen optimization level...
2018 Apr 03
2
[RFC] Adding function attributes to represent codegen optimization level
All, A recent commit, D43040/r324557, changed the behavior of the gold plugin when compiling with LTO. The change now causes the codegen optimization level to default to CodeGenOpt::Default (i.e., -O2) rather than use the LTO optimization level. The argument was made that the LTO optimization level should control the amount of cross-module optimizations done by LTO, but it should not control the codegen optimization level; that should be based off of the optimization lev...
2018 Apr 05
1
[RFC] Adding function attributes to represent codegen optimization level
Le mar. 3 avr. 2018 à 12:47, via llvm-dev <llvm-dev at lists.llvm.org> a écrit : > All, > A recent commit, D43040/r324557, changed the behavior of the gold plugin > when compiling with LTO. The change now causes the codegen optimization > level to default to CodeGenOpt::Default (i.e., -O2) rather than use the > LTO optimization level. The argument was made that the LTO optimization > level should control the amount of cross-module optimizations done by > LTO, but it should not control the codegen optimization level; that > should be based off of the...
2018 Apr 04
1
[RFC] Adding function attributes to represent codegen optimization level
..., Apr 3, 2018 at 12:47 PM via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > wrote: All, A recent commit, D43040/r324557, changed the behavior of the gold plugin when compiling with LTO. The change now causes the codegen optimization level to default to CodeGenOpt::Default (i.e., -O2) rather than use the LTO optimization level. The argument was made that the LTO optimization level should control the amount of cross-module optimizations done by LTO, but it should not control the codegen optimization level; that should be based off of the optimization level u...
2018 Apr 04
1
[RFC] Adding function attributes to represent codegen optimization level
...vm.org > <mailto:llvm-dev at lists.llvm.org>> wrote: > > All, > A recent commit, D43040/r324557, changed the behavior of the gold > plugin > when compiling with LTO.  The change now causes the codegen > optimization > level to default to CodeGenOpt::Default (i.e., -O2) rather than > use the > LTO optimization level.  The argument was made that the LTO > optimization > level should control the amount of cross-module optimizations done by > LTO, but it should not control the codegen optimization level; that &g...
2017 Dec 06
2
[AMDGPU] Strange results with different address spaces
> On Dec 6, 2017, at 02:28, Haidl, Michael <michael.haidl at uni-muenster.de> wrote: > > The IR goes through a backend agnostic preparation phase that brings it into SSA from and changes the AS from 0 to 1. This sounds possibly problematic to me. The IR should be created with the correct address space to begin with. Changing this in the middle sounds suspect. > After this
2018 Feb 07
1
retpoline mitigation and 6.0
...pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) /home/dwmw2/git/llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:801:0 #26 0x0000000003f8df15 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) /home/dwmw2/git/llvm/tools/c...
2017 Aug 23
2
Subtarget Initialization in <ARCH>TargetMachine constructor
...const TargetOptions &Options, >> Optional<Reloc::Model> RM, >> Optional<CodeModel::Model> CM, >> CodeGenOpt::Level OL, bool >> isLittle) >> : LLVMTargetMachine(T, computeDataLayout(TT, CPU, Options, isLittle), >> TT, >> CPU, FS, Options, getEffectiveRelocModel(TT, RM), >> getEffectiveCodeModel(CM), OL), >> Targe...
2018 Feb 07
4
retpoline mitigation and 6.0
I've landed the patch in r324449. Before we merge this into two different Clang release branches and almost immediately release one of them, I would really like someone to confirm that this patch works well with the Linux kernel. David, if you're up for that, it would be great. Alternatively, Guenter or someone else here can help. On Tue, Feb 6, 2018 at 5:59 PM Chandler Carruth
2017 Nov 27
2
[GlobalISel][AArch64] Toward flipping the switch for O0: Please give it a try!
...clang-6.0+0x30c9c53) > #14 0x00000000030ca136 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/work/llvm/build/bin/clang-6.0+0x30ca136) > #15 0x00000000037c3dcf clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) (/work/llvm/build/bin/clang-6.0+...
2017 Aug 22
4
[RFC] mir-canon: A new tool for canonicalizing MIR for cleaner diffing.
Patch for review. On Mon, Aug 21, 2017 at 11:45 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> wrote: > Ping. > > Still working on preparing code for review. Will have a patch for review > ready in the coming days. > > PL > > On Tue, Aug 15, 2017 at 12:06 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> > wrote: > >> Hi, >> >> >>