search for: amdgiz

...lue. Currently, this checking is done by isKnownNonZero() in ValueTracking, and it assumes alloca in address space 0 always has non-zero value but alloca in non-zero address spaces does not always have non-zero value. However, this assumption is incorrect for certain targets. For example, amdgcn---amdgiz target has alloca in address space 5, and its alloca always has non-zero value. This assumption causes some optimizations disabled for amdgcn---amdgiz target. After discussions at https://reviews.llvm.org/D40670, I propose to introduce TargetTransformInfo::isAllocaPtrValueNonZero for representing...

Hal, Thanks for your suggestion. I think that makes sense. Currently, non-zero alloca address space is already represented by data layout, e.g., the last component of the data layout of amdgcn---amdgiz target is -A5, which means alloca is in address space 5. How about adding a letter z to -A5 to indicate alloca may have zero value? i.e. -A5 means alloca is in address space 5 and always has non-zero value, -A5z means alloca is in address space 5 and may have zero value. Then we can add function D...

...8 249 250 251 252 253 254 255 Which is produced by the IR in as0.ll The only difference in the two IR dumps is that the parameters to the kernel are in different address spaces. https://llvm.org/docs/AMDGPUUsage.html#amdgpu-opencl states that address space 1 should be the global address space for amdgiz runtimes like ROCm and AS 0 is the generic (flat) address space. Is this working as intended and do I something wrong with the address spaces for AMDGPU or is this some undesired behavior and a possible bug? I am running the latest ROCm 1.6 on an AMD Vega RX 64 and llvm-trunk. Cheers, Michael --...