- User Since
- Jan 6 2015, 6:21 AM (211 w, 1 d)
Mon, Jan 14
Bah, the following patch poked holes in this Diff:
Wed, Jan 9
Tue, Jan 8
Sat, Dec 29
Dec 17 2018
Well, mayRaise Exception is purely a MI level flag. I struggle to see where optimizations on the MI level would ever care about rounding modes in the sense you describe: note that currently, MI optimizations don't even know which operation an MI instruction performs -- if you don't even know whether you're dealing with addition or subtraction, why would you care which rounding mode the operation is performed in? MI transformations instead care about what I'd call "structural" properties of the operation: what are the operands, what is input vs. output, which memory may be accessed, which special registers may involved, which other side effects may the operation have. This is the type of knowledge you need for the types of transformations that are done on the MI level: mostly about moving instructions around, arriving at an optimal schedule, de-duplicating identical operations performed multiple times etc. (Even things like simply changing a register operand to a memory operand for the same operation cannot be done solely by common MI optimizations but require per-target support.)
Dec 14 2018
Well, this is because I'm really only using this feature to handle exceptions (b.t.w. just like the MemOperands in the alternate attempt).
Rounding mode is handled completely in the back-end: we simply make all floating-point instructions (strict or not doesn't even matter here) use the FPC control register, and mark all instructions that change the rounding mode as changing FPC. The one missing piece is that we need to mark all function calls to functions marked as within FENV_ACCESS ON regions as also clobbering FPC -- that can be done easily in the target ABI code as soon as the front-end marks such function calls (which we need anyway).
@uweigand, it looks like you submitted some unintended changes with the last Diff update. Just FYI...
A quiet ping on this, since this is my last working day of the year...
I like this implementation a lot. Some targets control the FPEnv through a register, not through memory. Modeling instructions with register side-effects through MachineMemOperand wasn't intuitive.
Dec 5 2018
Revert back to mutating a temp before Custom lowering.
Dec 4 2018
Dec 3 2018
Remove setting of STRICT_FSETCC Custom lowering, as @uweigand suggested.
Nov 28 2018
This issue was handled with the addition of a dedicated FNeg IR Instruction in D53877.
Nov 27 2018
@uweigand, what about something like this patch? The STRICT_FSETCC isn't handled all the way through the target, but it's stubbed out for now.
Update TableGen changes, as suggested by @nhaehnle.
Digressing a bit, but has anyone given thought to how this implementation will play out with libraries? When running with traps enabled, libraries must be compiled for trap-safety. E.g. optimizations on a lib's code could introduce a NaN or cause a trap that does not exist in the code itself.
Nov 20 2018
Nov 19 2018
Nov 17 2018
Nov 16 2018
Fair enough. Just for conversation's sake, I was envisioning the FE support a little differently...
Abandon this Revision for D54649...
Nov 15 2018
Oh, right. I missed that. So there should probably be a new STRICT_SETCC node. Thanks.
I'm working on the changes that we discussed, but they're pretty invasive. A prospective patch is coming soon, but I wanted us to start thinking about how we'll handle these intrinsics at the SelectionDAG level. There are no CMP ISD nodes (also, what does legalization look like??), so this will likely be a significant change.
Good catch, @arsenm. Thanks.
Nov 14 2018
Nov 13 2018
@majnemer has approved the changes offline. Will commit this patch imminently...
Nov 12 2018
David also gave a LGTM for the call-and-invoke-with-ranges.ll change off-line. If he's okay with the function code number change in LLVMBitCodes.h, I'll go ahead and commit this patch.
Rebase and create new function code number, as suggested by @majnemer.
Nov 9 2018
Here's a first whack at a list of operations needed internally:
Nov 8 2018
Update test/Transforms/MergeFunc/call-and-invoke-with-ranges.ll to account for changes in the Instruction.def enum values.
Wow, that's great. Thanks, Matt!
Nov 7 2018
That's cool with me. Definitely a ton of work, but it's clean and complete.
Add bitcode tests for fastmath flags, as @arsenm suggested. Thanks for bearing with me, Matt.
Add two test/Bitcode tests and address one llvm-bcanalyzer issue, as suggested by @arsenm.
Ah, I think I see some problems with llvm-bcanalyzer. Will address...
Add newlines to lib/AsmParser/LLParser.cpp, as suggested by @arsenm.
Seems fair. I don't know enough about the Clang FE to have an opinion on that.
Nov 6 2018
All good points.
Nov 5 2018
Nov 2 2018
Rebase and remove extra '^' characters from docs/LangRef.rst.
Add a comment about not reordering the llvm-c/Core.h enum values, as @jyknight suggested.
Nov 1 2018
Don't reorder the members in llvm-c/Core.h as suggested by @jyknight.
Here's a quick example. You can see in the IR that the ConstantFolder picks up the FDiv as undefined:
I don't think this will work. The ConstantFolder could fold away traps early in the IRBuilder. We also wouldn't catch the FNeg/FSub case either.
Remove extra whitespace from test/Assembler/fast-math-flags.ll.
Add -strict-whitespace option.
Reorder LLVMAddrSpaceCast as @arsenm suggested.
Oct 31 2018
Updating diff to add test/Assembler tests. This includes both fastmath flags and double-round-tripping tests.
Oct 30 2018
Oct 25 2018
Whoops, forgot to update. Yeah, your vector test looks good now.