- User Since
- Jan 6 2015, 6:21 AM (201 w, 4 d)
Fair enough. Just for conversation's sake, I was envisioning the FE support a little differently...
Abandon this Revision for D54649...
Thu, Nov 15
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.
Wed, Nov 14
Tue, Nov 13
@majnemer has approved the changes offline. Will commit this patch imminently...
Mon, Nov 12
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.
Fri, Nov 9
Here's a first whack at a list of operations needed internally:
Thu, Nov 8
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!
Wed, Nov 7
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.
Tue, Nov 6
All good points.
Mon, Nov 5
Fri, Nov 2
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.
Thu, Nov 1
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.
Wed, Oct 31
Updating diff to add test/Assembler tests. This includes both fastmath flags and double-round-tripping tests.
Tue, Oct 30
Thu, Oct 25
Whoops, forgot to update. Yeah, your vector test looks good now.
Updating diff based on Sanjay's suggestions. One comment inline...
Wed, Oct 24
Tue, Oct 23
Rebase, add Sanjay's changes, and replace some more BinaryOperator::isFNeg(...) calls.
Mon, Oct 22
Ah, yeah. That would work. Thanks, Sanjay.
Fri, Oct 19
Just thinking aloud. I really don't have enough experience with this framework to say for sure...
Add support for FROUND and FTRUNC too.
Thu, Oct 18
Oct 18 2018
Oct 17 2018
Ah, yeah, there is a silent regression here. From BinaryOperator::isFNeg(...):
Oct 16 2018
Rebase to pick up Sanjay's changes...
Oct 13 2018
Oct 12 2018
Oct 9 2018
Bah, I forgot the "Differential Revision:" tag. This was committed with:
Move "NSZ" to be a suffix.
Update 'ignore signed zero' acronym to "NSZ".
Oct 8 2018
Oct 5 2018
Small update to remove superfluous parentheses.
Oct 4 2018
Sep 25 2018
There hasn't been any strong objects, but I haven't seen many strong accepts either besides the few main stakeholders. I'm under the assumption that silence is a passive reject in situations like this.
Sep 21 2018
It looks like an explicit FNEG operation isn't going to fly. I propose we drop that pursuit and continue forward with a constrained FNEG intrinsic.
Aug 24 2018
Did we decide that fast math flags can't be applied in the presence of constrained operations?