User Details
- User Since
- May 5 2014, 7:26 AM (419 w, 3 d)
Today
On what target are you seeing this problem?
Probably pull out the frem.ll and frem-libcall.ll tests into their own phab for review first - frem-libcall.ll in particular doesn't show the current problem in trunk (it generates 4 fmodf calls atm).
Yesterday
rebase
LGTM - cheers
LGTM - cheers
Thanks @kosarev - CodeGen\X86 should be clean now!
Testing more float types might be a good idea (bfloat / float / double / x86_fp80 / f128 / ppc_f128), even of they're negative tests - not sure how much the isDesirableIntType check is going to interfere?
Do you have many more examples of these patterns? If the addsub<->subadd pattern is the main problem it shouldn't take much to fix it later on in the backend
OK - speaking to @spatel offline there was a concern that AIC was becoming a bit of a dumping ground for combines that didn't really fit anywhere else.
LGTM - cheers
LGTM
LGTM
Tue, May 17
Are you needing the fp sat intrinsic to be visible in IR (better vectorization?) - otherwise might this be better off in CGP?
Mon, May 16
Not sure if this patch will be abandoned or refactored after D125457
LGTM
Restrict ADC/SBB folds to cases where the second op will be zero.
I can initially limit this to cases that create SBB $0, %REG patterns if you think it safer?
Sun, May 15
@0x59616e I'm seeing several "Decoding Conflict" warnings in M68k builds - e.g.:
Decoding Conflict: ................................................................0010...001010... ................................................................0010...00.010... ................................................................0010...00.01.... ................................................................0010......01.... ................................................................0010............ ................................................................................ MOV32aj 0010___001010___ MOV32aj_TC 0010___001010___
Sat, May 14
Sorry - my mistake - its a different test failure now!
@jhuber6 I think this or one of your other openmp commits has caused the Driver/cuda-openmp-driver.cu test failure here: https://lab.llvm.org/buildbot/#/builders/214/builds/1274/steps/6/logs/stdio
FWIW we might be able to perform something similar inside VectorCombine
LGTM - but maybe commit the define move seperately from the declare addition?
LGTM
Rebased after D124839 to just handle ISD::SRL shifts
Fri, May 13
LGTM
LGTM
It matches what we've done on X86 but I don't know if there's any reason MIPS has never added TTI support before? @sdardis might know the background.
@craig.topper @dmgreen Any objections?
Cheers @foad I've tried to clear up the summary