search for: noalias_sidechannel

Hi Alexey, Adding llvm-ir bitcode support means adding/adapting the tags for LOAD/STORE instructions and adding the support for the noalias_sidechannel at the right places. I had a short attempt to implement it when preparing the public patches, but I am not familiar with that part of the llvm code. When I noticed that it would take a lot longer than anticipated, I postponed it. Also because it is likely that the way how the noalias_sidechannel w...

...port triggers a problem, I would like to hear about it. - But, if it works and improves your benchmarks, I also would like to hear about it, either through phabricator, the llvm mailing list or in private. ## Known issues: - For now, there is still no llvm-ir bitcode support for the load/store noalias_sidechannel argument. - the 'SingleSource/Regression/C/gcc-c-torture/execute/GCC-C-execute-pr38212.test' in the 'test-suite' fails: -- the test is wrong as it triggers undefined behavior: it reads and writes the same object through 2 different restrict pointers which have been declared in...

...? 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 implementation deserves a separate document. (I am working on that one) - (2) they don't like the naming of 'noalias_sidechannel'. - (3) they also have some other mechanisms in mind to add the 'sidechannel' to the load/store instructions (and maybe to function calls, intrinsics; currently that is handled through llvm.noalias.arg.guard) For (2) and (3), I am waiting for a proposal from them ;) Greetings,...

...prevent it. > > > > During the Developers meeting, I also talked with Hal and Johannes. > > They had some extra remarks: > > - (1) the restrict implementation deserves a separate document. (I am > working on that one) > > - (2) they don't like the naming of 'noalias_sidechannel'. > > - (3) they also have some other mechanisms in mind to add the 'sidechannel' > to the load/store instructions > > (and maybe to function calls, intrinsics; currently that is handled through > llvm.noalias.arg.guard) > > > > For (2) and (3), I am...

...prevent it. > > > > During the Developers meeting, I also talked with Hal and Johannes. > > They had some extra remarks: > > - (1) the restrict implementation deserves a separate document. (I am > working on that one) > > - (2) they don't like the naming of 'noalias_sidechannel'. > > - (3) they also have some other mechanisms in mind to add the 'sidechannel' > to the load/store instructions > > (and maybe to function calls, intrinsics; currently that is handled through > llvm.noalias.arg.guard) > > > > For (2) and (3), I am...

...prevent it. > > > > During the Developers meeting, I also talked with Hal and Johannes. > > They had some extra remarks: > > - (1) the restrict implementation deserves a separate document. (I am > working on that one) > > - (2) they don't like the naming of 'noalias_sidechannel'. > > - (3) they also have some other mechanisms in mind to add the 'sidechannel' > to the load/store instructions > > (and maybe to function calls, intrinsics; currently that is handled through > llvm.noalias.arg.guard) > > > > For (2) and (3), I am...

...prevent it. > > > > During the Developers meeting, I also talked with Hal and Johannes. > > They had some extra remarks: > > - (1) the restrict implementation deserves a separate document. (I am > working on that one) > > - (2) they don't like the naming of 'noalias_sidechannel'. > > - (3) they also have some other mechanisms in mind to add the 'sidechannel' > to the load/store instructions > > (and maybe to function calls, intrinsics; currently that is handled through > llvm.noalias.arg.guard) > > > > For (2) and (3), I am waitin...

...prevent it. > > > > During the Developers meeting, I also talked with Hal and Johannes. > > They had some extra remarks: > > - (1) the restrict implementation deserves a separate document. (I am > working on that one) > > - (2) they don't like the naming of 'noalias_sidechannel'. > > - (3) they also have some other mechanisms in mind to add the 'sidechannel' > to the load/store instructions > > (and maybe to function calls, intrinsics; currently that is handled through > llvm.noalias.arg.guard) > > > > For (2) and (3), I am...