LGTM with a further change.
Fri, Jun 14
Thu, Jun 13
Use a debug loc with line 0 instead, fix a test that should have been using fastisel.
Wed, Jun 12
Tue, Jun 11
Mon, Jun 10
Sun, Jun 9
Looks much better, the GISel changes are fine.
Fri, Jun 7
Thu, Jun 6
Wed, Jun 5
Re-applied in r362666 with a fix. Thanks for reporting it.
The only comment I have is regarding the new namespace switchop: should we have one, should we have something camel case?
I don't feel strongly about it, just that it feels unusual compared to no namespace or existing camel cases ones ISD, RegAlloc, etc. We have non-camel case ones too, thus up to you.
Tue, Jun 4
Fri, May 31
Thu, May 30
Tue, May 28
LGTM. Can make a small change to make things a bit more concise but not very important.
Fri, May 24
Thu, May 23
LGTM with test nit.
Mon, May 20
Can you post the actual performance results? It's hard to judge whether 0.3% cost across the entire compiler is acceptable without knowing the benefits.
May 17 2019
May 16 2019
LGTM if no one else has comments.
May 13 2019
This patch is not correct -- the crash is not with varargs functions specifically, llvm also crashes for a function declared to explicitly take a float/double. The Win64 calling convention code assigns values to xmm registers, but it should not when sse is disabled.
Additionally, this patch unnecessarily breaks calling vararg functions with _integer_ arguments, which in particular, the EDK2 project does, with windows ABI functions and sse disabled. So, since this breaks existing working code, I'm going to revert this change now, and then propose a different change to address the crash.
Fair enough, I've reverted this in r360589. The test case seemed cumbersome to reduce and commit just for a threshold change, but I'm not sure what the best approach is here yet beyond a depth limit change.
May 10 2019
May 9 2019
Thanks for the explanations. I think you have some good points. Overall, it still looks to me like we're complicating things for backend writers and introducing a lot of subtle distinctions to keep in mind. It would be useful to hear what other people think about this.
May 8 2019
May 6 2019
We're seeing a failing assertion when building Skia for AArch64 which seems to have been introduced by this change, see PR41738 for more details.
Apr 28 2019
Apr 20 2019
Apr 19 2019
Apr 18 2019
Apr 17 2019
Yep, in that case might as well remove the entire helper.
Apr 16 2019
Reviving this as the overall approach was fine, it seems the alignment of non pow2 types is assumed to be the alignment of the next largest pow-2 type, so we don't need to worry about alignment during the breakdown.
I did however change the legalization method to not use extracts/inserts, but instead use extending loads and truncating stores, so that the artifacts get combined away and it Just Works.
I don't like how we do everything in bits, and then the mem operand forces bytes. Would it cost anything to switch MemOperands to also be in bits?