- User Since
- Feb 13 2015, 12:29 AM (119 w, 13 h)
Use getOperationAction as isOperationLegalOrCustom is breaking the AMDGPU backend for some reason. Remove formating change in wide-integer-cmp.ll .
I don't have a specific plan except it needs to be done and I got to figure out how to do it :)
Also remove SETCCE .
I usually do not work with clang. Do you have instructions I can follow to get that bc file ?
@RKSimon Most of these case aren't because node are not added to the worklist, but because of pattern that are somewhat deep - such as anything depending on KnownBits . Consider the following DAG:
Improve checks in constant_sextload_v8i16_to_v8i32 .
I'd rather remove it as part of D33390 than this one. Just in case something goes wrong, it'll be easier to revert.
Do not match sext and any_ext as this is invalid.
OK I was able to dig more. Something is screwed up with my test case. This is indeed not doing the right thing with the carry.
Wed, May 24
I have no idea what clang is doing there. It seems like the intrinsic do not map directly to the uaddo/usubo. See for yourself the generated IR (in clang 3.8 that's what I have available ATM):
Mon, May 22
Sun, May 21
This kicks in for fold-pcmpeqd-2.ll . Looking at the assembly, things looks good, but I'm not really sure what this test is testing for, so if someone familiar could advice on what to do, that'd be great. @chandlerc , @dblaikie you worked on that, can you advice ?
Fri, May 19
This is looking good and I like where this is going. I have a few nits in comments.
I looked at the codegen for the mul and it looks correct. There are very little actual changes, but, they do cause registers to be allocated differently, so the diff ends up being huge.
Wed, May 17
Mon, May 15
Wed, May 10
Remove NFC changes.
Add explicit EVT types.
Mon, May 8
Rebase on changes from D32916 .
Add an and in the pattern as to make the the value is 0 or 1.
Sat, May 6
Doing some refactoring to help the introduction of further diamond pattern simplification.
Fri, May 5
Rebase on top of D32925
Use getBoolExtOrTrunc .
Change the comment to explain the transform with some ASCII art.
Wed, May 3
Check for opcode before uses.
Tue, May 2
Rebase and use SDValue.
Sun, Apr 30
If you guys are good with it, then let's move forward. I have various patches coming based on this, and we start moving backends to use ADDCARRY instead of ADC once it is in.
Apr 24 2017
Add a FIXME on ADDC/SUBC to explain they are deprecated in favor of ADDCARRY and SUBCARRY and will be removed in the future.
I'd really would ike to move on with optimizing big integers better and this is gating everything. This needs to move forward.
Apr 21 2017
Ideally we'd like to have some test with this. The way it is usually done is to use the echo test: it reads a module using the C API and then recreate another identical module using the same C API. This ensure end to end testing. However this doesn't provide any reading facility so that me be more work than you are willing to put into this.
Hi, you can put "HEAD^" in the file ".git/arc/default-relative-commit" , this ensure that only the comit you are currently on is sent to phabricator.
Apr 20 2017
I think you have two green light, it's fine to proceed. Do you have commit rights ? If not I can commit this for you.
Apr 18 2017
Alternatively, I'm okay splitting this into smaller patches that are easier to decide about and test independently.
Apr 17 2017
It wouldn't upset me -- LLVMSwift is tracking LLVM latest and will continue to make breaking changes as the C API evolves. The real question is established bindings like the OCaml and python bindings -- would they be willing to use this API with breaking changes?
Is it acceptable for future releases of LLVM to break the C-API?
That's awesome. A few things.
Apr 10 2017
Apr 4 2017
Apr 3 2017
Mar 26 2017
Mar 20 2017
Update as per comments.