mugiwaraluffy56 wrote:
> As noted on the discussion in #179448, I think there's an underlying
> optimizer bug here. I'd prefer to address that first. (It's possible we
> should change the clang frontend behavior, but this particular testcase isn't
> demonstrating an issue.)
Thanks for the feedback @efriedma-quic.
I understand there might be an underlying optimizer issue. However, I believe
the CodeGen fix is still warranted because the mismatch between CreateIRTemp
(which uses the IR type i121) and CreateMemTemp (which uses the memory type
i128) for CoerceAndExpand returns causes the epilog to read the alloca with an
incorrect type assumption.
Even if the optimizer is fixed, having the alloca sized correctly for the
memory representation seems like the right behavior for CoerceAndExpand , the
coercion logic expects to read the value as {i64, i64} which requires the full
128-bit storage.
Would you be open to this as a defensive fix while the optimizer issue is
investigated? Or would you prefer I look into the optimizer side first? I'm
happy to dig into whichever approach you think is more appropriate.
https://github.com/llvm/llvm-project/pull/179456
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
