craig.topper added a comment. In D62731#1784491 <https://reviews.llvm.org/D62731#1784491>, @pengfei wrote:
> >> It's good that people are looking at achieving better modeling for the x86 > >> backend, but we need to have a plan that doesn't require heroic effort > >> just to get basic correctness. > > > > Do you mean in the backend? If so, I don't think that's possible. The > > backends just don't have any sort of feature that could be used to get > > conservatively correct behavior for cheap the way intrinsics give it to us > > in the middle end. Once you go into instruction selection things get very > > low level in a hurry. > > I'm looking for simple ways to modeling X86 intrinsics, but haven't find > better one than modeling it one by one. > > > I would suggest that we need a function/call attribute roughly on the level > > of `readonly` / `readnone`, maybe `readfponly`, that says that a function > > has no side-effects and no dependencies on anything *except* the FP state. > > Do you mean mark it at the declaration of intrinsics? Is it reasonable to > mark `except` on dependent intrinsics? > > > Basic queries like `Instruction::mayReadMemory()` that are supposed to be > > used generically in code-motion transforms would then return true for calls > > marked that way only if they're FP-constrained functions. > > Middle end or back end? I think in middle end you may need to change all > releated passes to get such information to prevent optimization. And in back > end, I think we can simply chain intrinsics marked `except` with other FP > nodes like what common code doing. We don't want to do this all the time. So we need a new property for the intrinsics that means we should prevent code motion in the middle end when the calling function has the strictfp attribute. Similarly SelectionDAGBuilder should use INTRINSIC_W_CHAIN instead of INTRINSIC_WO_CHAIN for any of these intrinsics when strictp is enabled. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62731/new/ https://reviews.llvm.org/D62731 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
