search for: ptr_proven

Displaying 7 results from an estimated 7 matches for "ptr_proven".

2019 Nov 12
2
Full restrict support - status update
...here are intrinsics to decode other kinds of information. > As an alternative, we could allow operand bundles on all instructions > and use them to tie information to an instruction. The "sidechannel" > operand of a load would then look something like: > load i32* %p [ "ptr_provenance"(%p_decl) ] > and for a store we could have > store i32** %p.addr, i32* %p [ "ptr_provenance"(%p_decl) ] > > The benefit is that we do not change the operand count (which causes a > lot of noise) but we still have to make sure ptr/value uses are not > confuse...
2019 Nov 06
2
Full restrict support - status update
Hi Alexey, >From: Alexey Zhikhartsev [..] > We would love to see your patches merged as soon as possible, so I was wondering: do you think the lack of bitcode support will prevent that from happening? Yes, I think that the lack of bitcode support will prevent it. During the Developers meeting, I also talked with Hal and Johannes. They had some extra remarks: - (1) the restrict
2020 May 13
2
LLVM Alias Analysis Technical Call - Doodle Poll
...here are intrinsics to decode other kinds of information. > As an alternative, we could allow operand bundles on all instructions > and use them to tie information to an instruction. The "sidechannel" > operand of a load would then look something like: > load i32* %p [ "ptr_provenance"(%p_decl) ] > and for a store we could have > store i32** %p.addr, i32* %p [ "ptr_provenance"(%p_decl) ] > > The benefit is that we do not change the operand count (which causes a > lot of noise) but we still have to make sure ptr/value uses are not > confused...
2020 May 18
4
LLVM Alias Analysis Technical Call - Doodle Poll
...here are intrinsics to decode other kinds of information. > As an alternative, we could allow operand bundles on all instructions > and use them to tie information to an instruction. The "sidechannel" > operand of a load would then look something like: > load i32* %p [ "ptr_provenance"(%p_decl) ] > and for a store we could have > store i32** %p.addr, i32* %p [ "ptr_provenance"(%p_decl) ] > > The benefit is that we do not change the operand count (which causes a > lot of noise) but we still have to make sure ptr/value uses are not > confused...
2020 May 21
2
LLVM Alias Analysis Technical Call - Doodle Poll
...there are intrinsics to decode other kinds of information. > As an alternative, we could allow operand bundles on all instructions > and use them to tie information to an instruction. The "sidechannel" > operand of a load would then look something like: > load i32* %p [ "ptr_provenance"(%p_decl) ] > and for a store we could have > store i32** %p.addr, i32* %p [ "ptr_provenance"(%p_decl) ] > > The benefit is that we do not change the operand count (which causes a > lot of noise) but we still have to make sure ptr/value uses are not > confused w...
2020 Jun 24
4
LLVM Alias Analysis Technical Call - New Doodle Poll
...here are intrinsics to decode other kinds of information. > As an alternative, we could allow operand bundles on all instructions > and use them to tie information to an instruction. The "sidechannel" > operand of a load would then look something like: > load i32* %p [ "ptr_provenance"(%p_decl) ] > and for a store we could have > store i32** %p.addr, i32* %p [ "ptr_provenance"(%p_decl) ] > > The benefit is that we do not change the operand count (which causes a > lot of noise) but we still have to make sure ptr/value uses are not > confused...
2020 Jun 24
2
FW: Restrict qualifier on class members
Hi Jeroen, Sorry, I missed that. I tried the patch, and this program: #include <stdint.h> #define __remote __attribute__((address_space(1))) __remote int* A; __remote int* B; void vec_add(__remote int* __restrict a, __remote int* __restrict b, int n) { #pragma unroll 4 for(int i=0; i<n; ++i) { a[i] += b[i]; } } int main(int argc, char** argv) {