https://github.com/koachan created
https://github.com/llvm/llvm-project/pull/77196
On 64-bit target, prefer usng RDPC over CALL to get the value of %pc.
This is faster on modern processors (Niagara T1 and newer) and avoids polluting
the processor's predictor state.
The old behavior of using a f
llvmbot wrote:
@llvm/pr-subscribers-backend-sparc
Author: Koakuma (koachan)
Changes
On 64-bit target, prefer usng RDPC over CALL to get the value of %pc.
This is faster on modern processors (Niagara T1 and newer) and avoids polluting
the processor's predictor state.
The old behavior of us
https://github.com/MaskRay created
https://github.com/llvm/llvm-project/pull/77221
Commit 8ed1d8196bef89c3099be4ce4aa65f613ab819cc made an AllocaInst
interesting only if
`!ClSkipPromotableAllocas || !isAllocaPromotable(&AI)`, which greatly
removed memory operand instrumention for -O0. However, t
llvmbot wrote:
@llvm/pr-subscribers-compiler-rt-sanitizer
Author: Fangrui Song (MaskRay)
Changes
Commit 8ed1d8196bef89c3099be4ce4aa65f613ab819cc made an AllocaInst
interesting only if
`!ClSkipPromotableAllocas || !isAllocaPromotable(&AI)`, which greatly
removed memory operand instrumention
llvmbot wrote:
@llvm/pr-subscribers-llvm-transforms
Author: Fangrui Song (MaskRay)
Changes
Commit 8ed1d8196bef89c3099be4ce4aa65f613ab819cc made an AllocaInst
interesting only if
`!ClSkipPromotableAllocas || !isAllocaPromotable(&AI)`, which greatly
removed memory operand instrumention for -
