- User Since
- May 15 2019, 8:43 PM (163 w, 4 h)
Is there any precedent for options that start with -maix or -m<OS> for any other OS?
Tue, Jun 28
Mon, Jun 27
Fri, Jun 24
Thu, Jun 23
Sun, Jun 19
Wed, Jun 15
LGTM as nemanja has detailed explanation for my concern.
Tue, Jun 14
This fix looks making offset handling more complex. We can make it easier by add LQX_PSEUDO and STQX_PSEUDO to ImmToIdxMap.
ImmToIdxMap[PPC::LQ] = PPC::LQX_PSEUDO; ImmToIdxMap[PPC::STQ] = PPC::STQX_PSEUDO;
And expand PPC::LQX_PSEUDO and PPC::STQX_PSEUDO post RA(They are expanded in PPCTargetLowering::EmitInstrWithCustomInserter right now). Thus we make LQ/STQ fits in how we are handling frame index now, no more code is needed to handling the offset for LQ/STQ(When LQ/STQ are selected by ISEL, alignment is guaranteed to be 16 bytes since they are for atomic operations).
Avoid using undef in tests.
Sun, Jun 12
Sat, Jun 11
Fri, Jun 10
Added original reduced case from @nemanjai .
Rebased to where float tests are added.
Tue, Jun 7
Mon, Jun 6
Sun, Jun 5
Wed, Jun 1
That would be expanded in PPCInstrInfo::expandPostRAPseudo()
I think the root cause here is lq/stq is leaking x-form. There are LQX_PSEUDO and STQX_PSEUDO defined to assist accessing big offset inside the stack, but there are expanded pre-RA. I think we should expand them in PPCAtomicExpandPass and make lq/stq's x-form mapping to LQX_PSEUDO/STQX_PSEUDO.
May 26 2022
I'm not sure if it's appropriate to use clang and compiler-rt in different versions. Added more reviewers for discussion.
May 22 2022
May 18 2022
May 17 2022
The problem (my concern) here is some architecture may not be ready to use isCopyInstr to identify what a COPY is.
Could you please describe briefly what copy-like instructions MCP is missing in the summary?
May 16 2022
May 8 2022
The troubled instruction was introduced for both P7 and A2 as below link shows:
May 4 2022
Apr 26 2022
Apr 19 2022
Apr 15 2022
Updated affected tests.
Apr 13 2022
Apr 11 2022
Apr 9 2022
The issue is fixed by https://reviews.llvm.org/D122868. We don't need to lower cfence when emitting __atomic* libcalls.
Apr 8 2022
Apr 7 2022
LGTM with nit.
Hi, this patch is breaking https://lab.llvm.org/buildbot/#/builders/37/builds/12263 https://lab.llvm.org/buildbot/#/builders/19/builds/10280, could you please take a look?
Apr 6 2022
Apr 5 2022
What this patch intended to do is covered by https://reviews.llvm.org/D120230.
Apr 1 2022
Mar 31 2022
Make 16-byte atomic type aligned to 16-byte on PPC64.
Could you also add test of opt -passes='default<O3>' to ensure we don't optimize it out for the motivation case?
Mar 28 2022
Thanks @efriedma for pointing out. Updated guard code. Removed -mllvm while adjusting backend to reflect ABI change.
Mar 25 2022
Removed alter of -ppc-quadword-atomcis in backend to decouple from frontend.
@dim @pkubaj We are modifying layout of 16-byte atomic type on Linux to be consistent with GCC, I don't know if it also applies to freebsd as @MaskRay pointed out.
To be more specific, on Linux, for arch level supporting 16-byte lock free atomics, 16-byte atomic type should be properly aligned.
Mar 24 2022
Please also add tests.
Most are covered by https://reviews.llvm.org/D122377 already.