pengfei added a comment. >> 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. 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
