ethanhs added a comment. In https://reviews.llvm.org/D47672#1121181, @rnk wrote:
> > They are a hint to the processor that this is a short critical section, and > it is likely that the entire critical section can be entered, run, and > committed to memory before another thread needs to use the memory used by the > critical section. Your implementation doesn't add these prefixes, but the > code will execute correctly. This functionality relies on TSX, which it looks > like Intel added some time in 2014, so it's probably widely available. > > Personally, I don't want to implement these intrinsics this way. We've > already implemented intrinsics "our way" instead of doing whatever Visual C > does, and it just leads to developer confusion when they discover that the > compiler didn't emit the instruction they want. For example, the rotate > intrinsics often don't work (https://llvm.org/pr37387) and the bittestandset > (bts) intrinsics are just broken (http://llvm.org/pr33188). I see. AIUI, the HLE versions just add optional hints, so there should not be any functional differences beyond using the hints or not (theses are optimization hints, yes?). Perhaps I misunderstood the documentation. > are there any plans for representing HLE hints on atomic instructions in LLVM > IR? This would be quite nice to have, the main reason I implemented these functions this way is I don't have the bandwidth at the moment to correctly implement HLE in LLVM/Clang, nor some of the requisite knowledge I'm sure. I also am keen to have Python build with clang-cl on Windows :) But I definitely can understand wanting to do things correctly from the start. I am going to the LLVM Bay Area monthly social Thursday so if someone wants to discuss this there I'd be more than happy to. Repository: rC Clang https://reviews.llvm.org/D47672 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
