- User Since
- Oct 15 2014, 9:44 AM (217 w, 6 d)
Mon, Dec 17
Oct 3 2018
Jul 31 2018
Jul 26 2018
A few minor comments inline, and one question: it sounds like this is based on a GCC feature; what's the expected behavior for __builtin_returnaddress ? Shouldn't it xpaci the result?
Jul 19 2018
LGTM. Not the biggest fan of CodeGen/Generic tests, but it gets the job done, I suppose ;) I wouldn't be surprised if it failed on some target that can't even handle half parameters, so you might want to load it instead, put it in x86, or wait and see - your pick.
Jun 28 2018
Jun 27 2018
Jun 13 2018
Jun 12 2018
Jun 10 2018
Jun 8 2018
Precisely: /usr/bin/env is recommended as a cross-platform way to find python. But:
- we're only using lldb on darwin, where we know python (or at least, the xcrun-style shortcut) is in /usr/bin/
- the python interpreter in LLDB comes from /S/L/F, for instance:
May 8 2018
May 4 2018
So, this makes sense to me, but on x86, should we also be worried about the fact that the calling convention is based on which features are available? (>128bit ext_vector_types are passed in AVX/AVX-512 registers, if available). Presumably swift is also affected, no?
Jan 4 2018
Clang/LLVM pieces LGTM. Thanks for doing this, people.
Dec 9 2017
Dec 7 2017
Nov 17 2017
Nov 9 2017
Sep 18 2017
Sep 12 2017
Aug 17 2017
Ah, that explains it. LGTM, thanks!
Aug 10 2017
Jul 27 2017
Jul 5 2017
There's a test for the call side in r294970, and I added some tests in r299093, you can probably make either check the generic fastisel fallback diagnostic too?
Jun 27 2017
This looks OK too.
Can you emit a single table for all patterns? I'm fine with doing that separately; looks OK otherwise.
Can you add a tablegen testcase? If nothing else, it's a good way to document the tablegen backend.
With the non-optimization comments addressed, I'm OK with this.
Jun 26 2017
Jun 16 2017
Jun 15 2017
Can you add a tablegen testcase?
LGTM without the pattern changes.
Jun 2 2017
May 15 2017
Huh, interesting.. Not a big deal, but can you avoid the #ifdef? Where was the overflow?
May 9 2017
D32766 replaced this; closing.
May 3 2017
May 2 2017
This looks fine; the TLI unittest is the best place for testing this. (for instance, no-proto.ll wouldn't help, because the pass doesn't know about these libfuncs and can't modify them anyway, regardless of the prototype)
May 1 2017
Apr 26 2017
Apr 25 2017
Apr 21 2017
Apr 20 2017
Apr 19 2017
Apr 17 2017
Apr 14 2017
LGTM, thanks for taking care of this!
Apr 13 2017
Makes sense to me. I wish we didn't need this, but progress is made one step at a time
Thanks folks! No objections for D31303 then?
16-bit is weird, but it'd be great if you could add a testcase for that.
Nice catch, LGTM.
Apr 12 2017
You're right, this is probably the best path forward. A few nits inline
Apr 10 2017
I'm slightly worried that this makes the selector functions a bit harder to read, but this seems like a nice simplification otherwise.
Does this really depend on D31329? Can you invert the dependency and put the tblgen emission bits in that patch?
Apr 6 2017
I'm not a big fan of this approach (because the iterative logic seems like it does belong in the helper), but it's mostly fine (we don't have users other than Legalizer), and it sounds like Tim and Quentin are on board. So, LGTM.