LGTM

LGTM

Moved check into opCanUseInlineConstant().
Captured subtarget in SIRegisterInfo to do this.

In D66670#1643525, @arsenm wrote:

Can these be encoded as a constant literal instead? We would then just need to workaround the encoding rather than disallowing the operand

In D66670#1643408, @arsenm wrote:

In D66670#1643385, @rampitec wrote:

In D66670#1643378, @arsenm wrote:

In D66670#1643370, @rampitec wrote:

In D66670#1643363, @arsenm wrote:

Can we have different opcodes with a different source type?

It will be a quite big change. What for?

Generally if the operand/register class changes there should be a separate opcode. It avoids needing all this special case checking, and makes folding code work naturally

Anyway, you cannot have two opcodes with the same opcode without introducing a new encoding and a new decoder namespace. This bug will be fixed.

The encoding is the same, and a new decoder namespace shouldn't be an issue

In D66670#1643378, @arsenm wrote:

In D66670#1643370, @rampitec wrote:

In D66670#1643363, @arsenm wrote:

Can we have different opcodes with a different source type?

It will be a quite big change. What for?

Generally if the operand/register class changes there should be a separate opcode. It avoids needing all this special case checking, and makes folding code work naturally

In D66670#1643363, @arsenm wrote:

Can we have different opcodes with a different source type?

LGTM

LGTM

In D66430#1635667, @arsenm wrote:

In D66430#1635664, @rampitec wrote:

In D66430#1635654, @arsenm wrote:

This pass should be removed. Clang needs to emit a separate function body up-front. I want the IR verifier to reject all calls to kernels. Since a module may need to export a callable function with the name of the kernel, this has a name mangling impact that the frontend needs to take care of

I agree in general. However, we do not support late linking so far but do support OpenCL. Is there any reason to keep this pass even as a temporary solution in the private branch?

I can't imagine the clang patch is a lot of work, but nobody's ever done it. Ignoring the name mangling problem, it shouldn't be difficult to just emit the two separate functions directly

In D66430#1635654, @arsenm wrote:

This pass should be removed. Clang needs to emit a separate function body up-front. I want the IR verifier to reject all calls to kernels. Since a module may need to export a callable function with the name of the kernel, this has a name mangling impact that the frontend needs to take care of

LGTM

Didn't you forget to update test/CodeGenOpenCL/amdgpu-features.cl?

LGTM

LGTM

In D24035#1626346, @eugenis wrote:

It's a bit hard to use, you need to build libcxx/libcxxabi with msan as well.
See here:
https://github.com/google/sanitizers/wiki/MemorySanitizerBootstrappingClang

I've started a build with track-origins here:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-msan/builds/14114
It could give more information.

In D24035#1626326, @rampitec wrote:

In D24035#1626306, @eugenis wrote:

Hi, MSan is complaining about this change:
==28574==WARNING: MemorySanitizer: use-of-uninitialized-value

#0 0x130075d in (anonymous namespace)::AMDGPUPrintfRuntimeBinding::lowerPrintfForGpu(llvm::Module&) /b/sanitizer-x86_64-linux-fast/build/llvm/lib/Target/AMDGPU/AMDGPUPrintfRuntimeBinding.cpp:576:39
#1 0x12f8287 in (anonymous namespace)::AMDGPUPrintfRuntimeBinding::runOnModule(llvm::Module&) /b/sanitizer-x86_64-linux-fast/build/llvm/lib/Target/AMDGPU/AMDGPUPrintfRuntimeBinding.cpp:613:10
#2 0x544a96d in runOnModule /b/sanitizer-x86_64-linux-fast/build/llvm/lib/IR/LegacyPassManager.cpp:1750:27
#3 0x544a96d in llvm::legacy::PassManagerImpl::run(llvm::Module&) /b/sanitizer-x86_64-linux-fast/build/llvm/lib/IR/LegacyPassManager.cpp:1863
#4 0x9e58b7 in main /b/sanitizer-x86_64-linux-fast/build/llvm/tools/opt/opt.cpp:892:12
#5 0x7f84fa91f2e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
#6 0x91ce99 in _start (/b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/bin/opt+0x91ce99)

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/34295/steps/check-llvm%20msan/logs/stdio

Thanks! I will check it.

In D24035#1626306, @eugenis wrote:

Hi, MSan is complaining about this change:
==28574==WARNING: MemorySanitizer: use-of-uninitialized-value

#0 0x130075d in (anonymous namespace)::AMDGPUPrintfRuntimeBinding::lowerPrintfForGpu(llvm::Module&) /b/sanitizer-x86_64-linux-fast/build/llvm/lib/Target/AMDGPU/AMDGPUPrintfRuntimeBinding.cpp:576:39
#1 0x12f8287 in (anonymous namespace)::AMDGPUPrintfRuntimeBinding::runOnModule(llvm::Module&) /b/sanitizer-x86_64-linux-fast/build/llvm/lib/Target/AMDGPU/AMDGPUPrintfRuntimeBinding.cpp:613:10
#2 0x544a96d in runOnModule /b/sanitizer-x86_64-linux-fast/build/llvm/lib/IR/LegacyPassManager.cpp:1750:27
#3 0x544a96d in llvm::legacy::PassManagerImpl::run(llvm::Module&) /b/sanitizer-x86_64-linux-fast/build/llvm/lib/IR/LegacyPassManager.cpp:1863
#4 0x9e58b7 in main /b/sanitizer-x86_64-linux-fast/build/llvm/tools/opt/opt.cpp:892:12
#5 0x7f84fa91f2e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
#6 0x91ce99 in _start (/b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/bin/opt+0x91ce99)

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/34295/steps/check-llvm%20msan/logs/stdio

Cleaned, updated and rebased.
Pass does not require prelink infrastructure anymore.

LGTM

LGTM

Changes to sextOrTrunc().

This one will go through our internal extended testing first, just to be sure it did not break anything.

Test update.

In D65480#1607350, @arsenm wrote:

Was this broken by r365723? Should this use stripPointerCastsSameRepresentation instead?

LGTM

LGTM

Removed "GCNSubtarget::getMaxWavesPerEU()" in favor of using "AMDGPUSubtarget::getMaxWavesPerEU;"

Added field MaxWavesPerEU instead of virtualizing the function.