Page MenuHomePhabricator
Feed Advanced Search

Tue, Apr 6

uweigand added a comment to D97514: [SystemZ] Assign the full space for promoted and split outgoing args.

Thanks for the heads-up, @luismarques ! However, this is not really an issue on SystemZ as all arguments in question have an alignment requirement of 8 bytes on our platform.

Tue, Apr 6, 7:51 AM · Restricted Project

Mon, Mar 15

uweigand accepted D97901: [SystemZ] Test for infinity in testFPKind()..

LGTM, thanks!

Mon, Mar 15, 1:40 PM · Restricted Project

Mar 12 2021

uweigand added inline comments to D98276: [AsmParser][SystemZ][z/OS] Introducing HLASM Parser support to AsmParser - Part 1.
Mar 12 2021, 9:14 AM · Restricted Project
uweigand added inline comments to D98276: [AsmParser][SystemZ][z/OS] Introducing HLASM Parser support to AsmParser - Part 1.
Mar 12 2021, 12:31 AM · Restricted Project

Mar 11 2021

uweigand added a comment to D97975: [libFuzzer] add attribute noinline on Fuzzer::ExecuteCallback().

I don't think there is a s390x platform-specific problem involved here at all, so I'm not sure disabling the test for the platform is the right fix.

Mar 11 2021, 3:18 AM · Restricted Project

Mar 4 2021

uweigand accepted D97748: [SystemZ][z/OS] Add support to validate a HLASM Label..

LGTM, thanks.

Mar 4 2021, 7:13 AM · Restricted Project
uweigand added inline comments to D97901: [SystemZ] Test for infinity in testFPKind()..
Mar 4 2021, 3:55 AM · Restricted Project

Mar 3 2021

uweigand accepted D97604: [SystemZ] Reimplement the 1-byte compare-and-swap logic.

Ahh, you're right. It's done in common code by the default ATOMIC_CMP_SWAP_SUCCESS expander -- but we're not using that since we use our own custom expander! So it indeed has to be done there in the back end.

Mar 3 2021, 11:05 AM · Restricted Project
uweigand added a comment to D97604: [SystemZ] Reimplement the 1-byte compare-and-swap logic.

The change in lowerATOMIC_CMP_SWAP should be removed now. Otherwise this LGTM.

Mar 3 2021, 1:16 AM · Restricted Project

Mar 2 2021

uweigand added inline comments to D97748: [SystemZ][z/OS] Add support to validate a HLASM Label..
Mar 2 2021, 12:53 AM · Restricted Project
uweigand added a comment to D97604: [SystemZ] Reimplement the 1-byte compare-and-swap logic.

I added an AND to zero-out the high bits to perform the zero-extension from the narrow type. It seemed that if the source was a constant (e.g. '1'), the DAG.getNode(ISD::AND, ...) call folded the AND on the fly. And if the source was a parameter with the 'zeroext' attribute (or rather any result with an AssertZext node) ,the AND goes away during DAGCombine2. So for what I could see, there is not much extra work to do here.

Mar 2 2021, 12:47 AM · Restricted Project
uweigand accepted D97514: [SystemZ] Assign the full space for promoted and split outgoing args.

LGTM, thanks!

Mar 2 2021, 12:27 AM · Restricted Project

Mar 1 2021

uweigand accepted D97581: [SystemZ] Introduce distinction between the jg/jl family of mnemonics for GNU as vs HLASM.
  • Improved the implementation of MnemonicCondBranch by abstracting away details from SystemZInstrInfo.td
  • For this, a multi-class had to be used.
Mar 1 2021, 9:06 AM · Restricted Project
uweigand added inline comments to D97514: [SystemZ] Assign the full space for promoted and split outgoing args.
Mar 1 2021, 5:51 AM · Restricted Project
uweigand added a comment to D97604: [SystemZ] Reimplement the 1-byte compare-and-swap logic.

CmpVal: Should not need a LL[HC]R, as it should already be zero-extended also in the case of a non-constant, or?

Mar 1 2021, 5:20 AM · Restricted Project
uweigand added a comment to D97581: [SystemZ] Introduce distinction between the jg/jl family of mnemonics for GNU as vs HLASM.

Looks good in general. Just as a cosmetic issue, it would be nicer to be able to simply write:

Mar 1 2021, 4:05 AM · Restricted Project

Feb 26 2021

uweigand accepted D94250: [SystemZ] Introducing assembler dialects for the Z backend.

Looks like resolving the general issues with the AsmDialect setting is more complicated than I thought and may still take a while.

Feb 26 2021, 4:23 AM · Restricted Project
uweigand added a comment to D97514: [SystemZ] Assign the full space for promoted and split outgoing args.

I'm not sure if "getTypeToTransformTo(*DAG.getContext(), OrigArgVT)" results in the same type that is used by common code in all cases.

Feb 26 2021, 4:12 AM · Restricted Project

Feb 19 2021

uweigand accepted D96887: [SystemZ/z/OS] Initial changes to add the XPLink calling convention to tablegen.

LGTM, thanks!

Feb 19 2021, 5:39 AM · Restricted Project

Feb 18 2021

uweigand accepted D96568: [CFE, SystemZ] Emit s390.tdc instrincic for __builtin_isnan in Constrained FP mode..

LGTM as well, thanks!

Feb 18 2021, 2:42 AM · Restricted Project

Feb 17 2021

uweigand accepted D96867: [SystemZ] Separate LoZ ELF specifics in tablegen.

LGTM, thanks!

Feb 17 2021, 8:04 AM · Restricted Project

Feb 12 2021

uweigand added a comment to D96568: [CFE, SystemZ] Emit s390.tdc instrincic for __builtin_isnan in Constrained FP mode..

That's interesting. I presume that can be used to implement isinf as well? Perhaps better call the hook fpclassify or similar?

Feb 12 2021, 3:43 AM · Restricted Project

Feb 11 2021

uweigand added a comment to D96471: [SystemZ] Fix vecintrin.h to not emit alignment hints in vec_xl/vec_xst..

It's not a good idea to use the library routine "memcpy" here, because the name in theory be redefined by a user before including the header, and also there may not be a prototype in scope causing warnings when building with -Wall.

Feb 11 2021, 10:53 AM · Restricted Project

Feb 9 2021

uweigand added inline comments to D95444: Allow GNU inline asm using target-specific dialect variant.
Feb 9 2021, 1:46 AM · Restricted Project

Feb 8 2021

uweigand added a comment to D95444: Allow GNU inline asm using target-specific dialect variant.

At least for our use case, this is not relevant. We want to use the "GCC style asm" whenever compiling for the z/OS target, and the "HLASM style asm" whenever compiling for the Linux target. These are incompatible anyway (different ABI, different target OS), so they cannot be combined using LTO. We simply need to use asm dialects since both targets are implemented in a single SystemZ back-end. (While the OS and ABI are different, the ISA is of course the same, so it does not make sense to use a different back-end.)

@uweigand, its the other way right? We want to use the "GNU style asm" when compiling for the Linux target (on the Z backend) and use the "HLASM style asm" when compiling for the z/OS target (on the Z backend).

Feb 8 2021, 10:02 AM · Restricted Project
uweigand added a comment to D95444: Allow GNU inline asm using target-specific dialect variant.
In D95444#2546235, @rnk wrote:

Yes, sorry, I meant the assembly dialect that the GNU binutils assembler parses. What I'm trying to get at is that you might want to support separate blobs that use different dialects:

void foo() { asm volatile ("gnu style asm"); }
void bar() { asm volatile ("HLASM style asm"); }

If there is one global setting for the inline asm dialect, this won't work. You could create a flag to control the setting, but then if you want to use LTO on two objects that use different assembly dialects, the command line flag isn't sufficient. To fully address this use case, you would want to put the dialect on each inline assembly blob, similar to the way we handle the existing intel/gnu dialect flag.

Feb 8 2021, 3:45 AM · Restricted Project

Jan 26 2021

uweigand added a comment to D82862: [ThinLTO] Always parse module level inline asm with At&t dialect.
In D82862#2513044, @rnk wrote:

So why do you want GNU inline asm for clang-cl anyway? I thought the whole point of clang-cl was to be compatible with the Microsoft Visual Studio compiler, which I understand only supports the MS asm syntax?

We have users, in this case, I think it's V8, who would prefer to use gcc-style module level assembly if it is available. Their motivation is somewhat arbitrary, but generally, clang-cl supports a variety of extensions, some inherited from GCC, in all modes. Part of the point of switching compilers from MSVC to clang is to get access to those extensions.

Jan 26 2021, 7:12 AM · Restricted Project, Restricted Project
uweigand requested review of D95444: Allow GNU inline asm using target-specific dialect variant.
Jan 26 2021, 7:09 AM · Restricted Project

Jan 21 2021

uweigand added a comment to D82862: [ThinLTO] Always parse module level inline asm with At&t dialect.

The motivation for my change was really just to make ThinLTO compiles work the same as non-ThinLTO ones.

Maybe the fact that -x86-asm-syntax=intel doesn't affect inline asm is a bug. I wasn't aware that Clang and GCC's -masm= flags behaved differently in that way, but that certainly suggests there's a problem here.

So I'm wondering, if I remove the above setAssemblerDialect line and revert this commit, we should have inline asm (both module-level and GNU function-leve) respect the target-selected asm dialect variant both for ThinLTO and non-ThinLTO, so they should match again. Would that also solve the problem you were originally tracking?

Not completely, because clang-cl sets -x86-asm-syntax=intel to enable intel-style asm in assembly listing output. We'd have to find another way of doing that without affecting the inline asm dialect.

Jan 21 2021, 9:36 AM · Restricted Project, Restricted Project
uweigand committed rGb3a5abcb3696: [NFC][Doc] Mention SystemZ supports StackMap generation (authored by uweigand).
[NFC][Doc] Mention SystemZ supports StackMap generation
Jan 21 2021, 9:31 AM
uweigand closed D95040: [NFC][Doc] Mention SystemZ supports StackMap generation.
Jan 21 2021, 9:31 AM · Restricted Project

Jan 20 2021

uweigand accepted D95040: [NFC][Doc] Mention SystemZ supports StackMap generation.

LGTM, thanks!

Jan 20 2021, 6:23 AM · Restricted Project

Jan 15 2021

uweigand added a comment to D82862: [ThinLTO] Always parse module level inline asm with At&t dialect.

What is the reason for treating this differently in LLVM?

I'm not sure if it is related to this. I think one difference is that LLVM is supporting MS inline assembly. Although it uses Intel dialect, it has different representation in input, output, clobber etc. with GCC'.

Jan 15 2021, 3:51 AM · Restricted Project, Restricted Project

Jan 14 2021

uweigand added a comment to D94250: [SystemZ] Introducing assembler dialects for the Z backend.

Just a quick comment that I'm looking at this, but before approval I want to resolve the issues described in the comment in front of getMAIAssemblerDialect. See also discussion here: https://reviews.llvm.org/D82862

Jan 14 2021, 7:17 AM · Restricted Project
uweigand added a comment to D82862: [ThinLTO] Always parse module level inline asm with At&t dialect.

Hi @hans , we're having some issues with using the AssemblerDialect mechanism to support both the GNU assembler and the IBM HLASM assembler in the SystemZ back-end. See also the discussion started here: https://lists.llvm.org/pipermail/llvm-dev/2020-November/146875.html

Jan 14 2021, 7:15 AM · Restricted Project, Restricted Project

Jan 13 2021

uweigand accepted D94383: [SystemZ] Don't crash with -misched-cutoff.

LGTM

Jan 13 2021, 1:07 AM · Restricted Project

Jan 12 2021

uweigand added a comment to D94383: [SystemZ] Don't crash with -misched-cutoff.

I don't think we need to bother with skipping advancing the hazard state. I believe the main point of the cutoff is to avoid combinatorial explosion where there are many instructions to schedule and at each step there are many candidates to consider. Advancing the hazard state doesn't consider candidates and is therefore just a linear pass over instructions.

Jan 12 2021, 2:00 AM · Restricted Project

Jan 11 2021

uweigand added a comment to D94383: [SystemZ] Don't crash with -misched-cutoff.

Could you elaborate why initPolicy is the correct place to clear the Available list? I'm wondering because the default implementation doesn't appear to do that either, it looks like common code only clears the list in the main "init" ...

Jan 11 2021, 5:29 AM · Restricted Project

Dec 16 2020

uweigand accepted D93388: [Doc][SystemZ] Add Linux/SystemZ to Getting Started guide..

LGTM, thanks!

Dec 16 2020, 7:25 AM · Restricted Project

Dec 15 2020

uweigand committed rGebef92169ca5: [SystemZ] Remove most hard-coded R1D instances for sibcalls (authored by uweigand).
[SystemZ] Remove most hard-coded R1D instances for sibcalls
Dec 15 2020, 7:32 AM

Dec 14 2020

uweigand accepted D93171: [SystemZ] Improve handling of backchain offset.

This all looks good to me, the test case also looks fine (and the offset match what GCC is doing).

Dec 14 2020, 9:23 AM · Restricted Project

Dec 11 2020

uweigand accepted D92985: [SystemZTTIImpl::getMinPrefetchStride] Allow some non-prefetched mem accesses..

OK, I think this is fine then.

Dec 11 2020, 12:30 AM · Restricted Project
uweigand accepted D92803: [SystemZFrameLowering] Make sure R1 holding the backchain is not corrupted by probing .

Ah, OK . Looks good to me.

Dec 11 2020, 12:29 AM · Restricted Project

Dec 10 2020

uweigand accepted D92803: [SystemZFrameLowering] Make sure R1 holding the backchain is not corrupted by probing .

This suggestion wasn't for performance reasons, but correctness. In theory, when using the backchain, it should be updated on every change to %r15 so that %r15 at all times points to a valid backchain value. Otherwise, unwinding using the backchain will randomly fail when starting at some PC where the stack pointer has been updated but the backchain not yet written.

Dec 10 2020, 2:13 AM · Restricted Project
uweigand added a comment to D92985: [SystemZTTIImpl::getMinPrefetchStride] Allow some non-prefetched mem accesses..

It doesn't seem right to bail just for one non-prefetched access, so it seems reasonable to allow a relatively very small amount of non-prefetched instructions, to make the heuristic more stable. This patch suggests allowing 1 non-prefetched memory access per 32 prefetched ones. This handles LBM, and also gives two prefetches to imagick which however do not seem to play a role.

Dec 10 2020, 1:52 AM · Restricted Project

Dec 9 2020

uweigand added a comment to D92803: [SystemZFrameLowering] Make sure R1 holding the backchain is not corrupted by probing .

I think it still makes sense to have the backchain store local in inlineStackProbe.

Dec 9 2020, 10:20 AM · Restricted Project

Dec 8 2020

uweigand added a comment to D92803: [SystemZFrameLowering] Make sure R1 holding the backchain is not corrupted by probing .

I'm not sure I like the implicit assumptions the patch makes between inlineStackProbe and emitPrologue.

Dec 8 2020, 12:56 AM · Restricted Project

Nov 27 2020

uweigand accepted D92185: [SystemZ] Adding extra extended mnemonics for SystemZ target.

LGTM, thanks!

Nov 27 2020, 9:03 AM · Restricted Project
uweigand added a comment to D92185: [SystemZ] Adding extra extended mnemonics for SystemZ target.

This looks good to me. The only thing I'm wondering is whether we shouldn't complete the NOP set by adding a 6-byte "jgnop". (I guess this is called jlnop with HLASM, but in order to keep with the jg* naming scheme in GAS we probably ought to use jgnop here.)

Nov 27 2020, 1:41 AM · Restricted Project

Nov 24 2020

uweigand accepted D91962: Add support for STRICT_FSETCC promotion.

LGTM, thanks!

Nov 24 2020, 6:23 AM · Restricted Project
uweigand added a comment to D91962: Add support for STRICT_FSETCC promotion.

OK, I see. I guess the patch LGTM then with the two issues fixed.

Nov 24 2020, 5:48 AM · Restricted Project
uweigand added a comment to D91962: Add support for STRICT_FSETCC promotion.

See the two inline comments about STRICT_FSETCCS. I guess that shows this path is not really exercised right now -- maybe it would be a good idea to add some tests.

Nov 24 2020, 5:32 AM · Restricted Project

Nov 23 2020

uweigand added a comment to D91962: Add support for STRICT_FSETCC promotion.

Oh, any another thing: we might also want to handle STRICT_FSETCCS in addition to STRICT_FSETCC.

Nov 23 2020, 10:28 AM · Restricted Project
uweigand requested changes to D91962: Add support for STRICT_FSETCC promotion.
Nov 23 2020, 10:23 AM · Restricted Project

Nov 18 2020

uweigand accepted D91697: [SystemZ] Use ISD::ABS opcode during isel.

LGTM, thanks!

Nov 18 2020, 5:09 AM · Restricted Project

Nov 17 2020

uweigand added a comment to D91120: [DAGCombine][PowerPC] Convert negated abs to trivial arithmetic ops.

It seems strange that we would need to add a TLI hook to avoid regressing a target that has abs/nabs support in the ISA.
If I'm seeing it correctly, SystemZ relies on ISD::ABS being expanded and then pattern-matching the expansion back to lpgr for example. Could we change that target to declare ISD::ABS as legal and adjust the tablegen matching for it?

Nov 17 2020, 7:10 AM · Restricted Project

Nov 9 2020

uweigand added a comment to D90760: [InstCombiner] Make LibCallSimplifier add extension attribute to ldexp arg..

I'm not sure whether the call instruction must match the declaration w.r.t. extension attributes. In the IR generated by clang, the two always match:

Nov 9 2020, 7:50 AM · Restricted Project

Nov 4 2020

uweigand added a comment to D90760: [InstCombiner] Make LibCallSimplifier add extension attribute to ldexp arg..

This doesn't look quite right to me. ldexp has a signed "int" argument, so you always must use the "sext" sign extension attribute on that argument.

Nov 4 2020, 7:22 AM · Restricted Project

Oct 28 2020

uweigand committed rGa998cae0210f: [compiler-rt][SystemZ] Skip fuzzer/full-coverage.test (authored by uweigand).
[compiler-rt][SystemZ] Skip fuzzer/full-coverage.test
Oct 28 2020, 8:40 AM
uweigand added a comment to D90231: [GVN] Don't replace argument to @llvm.is.constant.*().

I think it makes general sense to not optimize the argument to @llvm.is.constant.

Oct 28 2020, 2:11 AM · Restricted Project

Oct 23 2020

uweigand accepted D90065: [SystemZ] Define MaxInstLength to have the value of 6..

Note: The python tests show up as UNSUPPORTED when I try to run them with llvm-lit. I could not find out how to enable them.

Oct 23 2020, 1:53 PM · Restricted Project

Oct 21 2020

uweigand accepted D89451: [SystemZ] Mark unsaved argument R6 as live throughout function.

See inline comment; otherwise this LGTM.

Oct 21 2020, 5:18 AM · Restricted Project

Oct 20 2020

uweigand committed rGc299f3555d77: [SystemZ] Fix disassembler crashes (authored by uweigand).
[SystemZ] Fix disassembler crashes
Oct 20 2020, 1:22 AM

Oct 16 2020

uweigand added inline comments to D89451: [SystemZ] Mark unsaved argument R6 as live throughout function.
Oct 16 2020, 5:30 PM · Restricted Project
uweigand added a comment to D87279: [clang] Fix handling of physical registers in inline assembly operands..

The problem seems to be with a tied earlyclobber operand:

asm("" : "+&r"(a));

Per the comment in InlineAsm::ConstraintInfo::Parse(), only output can be earlyclobber.

I am not sure if the earlyclobber ('&') should with this patch be removed from the added use of the register, or if this has to for some reason really be tied to the def?

Oct 16 2020, 5:32 AM · Restricted Project
uweigand added inline comments to D89451: [SystemZ] Mark unsaved argument R6 as live throughout function.
Oct 16 2020, 1:57 AM · Restricted Project

Oct 15 2020

uweigand updated subscribers of D89447: [MachineInstr] Add support for instructions with multiple memory operands..

@jonpa can you check whether the SystemZ test case you added still checks what it was intended to check here?

Oct 15 2020, 9:58 AM · Restricted Project

Oct 14 2020

uweigand accepted D89389: [SystemZ] Bugfix in SystemZVectorConstantInfo.

Strange that this wasn't noticed earlier. In any case, patch LGTM.

Oct 14 2020, 6:12 AM · Restricted Project

Oct 9 2020

uweigand accepted D89034: [SystemZ] Use LA instead of AGR in eliminateFrameIndex()..

LGTM, thanks!

Oct 9 2020, 2:05 AM · Restricted Project

Oct 8 2020

uweigand added inline comments to D89034: [SystemZ] Use LA instead of AGR in eliminateFrameIndex()..
Oct 8 2020, 7:49 AM · Restricted Project

Oct 6 2020

uweigand added a comment to D88888: [SystemZAsmParser] Treat VR128 separately in ParseDirectiveInsn()..

See inline comment. Otherwise LGTM.

Oct 6 2020, 5:25 AM · Restricted Project
uweigand added a comment to D88817: [llvm-readobj/elf] - Ignore the hash table when on EM_S390/EM_ALPHA platforms..

It looks like this will trigger a warning being emitted on every use of llvm-readobj on a EM_S390 object file, which is probably not what we want. (They all also contain .gnu.hash, so the fact that .hash is ignored is not anything that the user should be concerned about. -- This warning may just cause unnecessary confusion, or parse error with automated tools etc.)

I'd like to wait for opinions of @jhenderson/@MaskRay to confirm them are happy to silently ignore the .hash section on EM_S390/EM_ALPHA platforms. It might probably
be confusing to see a .hash section in an object and no output with --hash-table.

Oct 6 2020, 1:17 AM · Restricted Project

Oct 5 2020

uweigand added a comment to D88817: [llvm-readobj/elf] - Ignore the hash table when on EM_S390/EM_ALPHA platforms..

It looks like this will trigger a warning being emitted on every use of llvm-readobj on a EM_S390 object file, which is probably not what we want. (They all also contain .gnu.hash, so the fact that .hash is ignored is not anything that the user should be concerned about. -- This warning may just cause unnecessary confusion, or parse error with automated tools etc.)

Oct 5 2020, 4:47 AM · Restricted Project
uweigand accepted D88357: [SystemZ] Add support for .insn directives for vector instructions.

See the inline question about vector registers. This does not affect the current patch however, so this should be good to go in. LGTM.

Oct 5 2020, 4:44 AM · Restricted Project

Oct 2 2020

uweigand added inline comments to D88357: [SystemZ] Add support for .insn directives for vector instructions.
Oct 2 2020, 9:57 AM · Restricted Project

Oct 1 2020

uweigand added a comment to D88561: [llvm-readobj] - Fix possible crashes related to dumping gnu hash symbols..

I see. In this case this patch doesn't really address PR47681, but only replaces a crash with wrong output ... Still preferable to not crash, but of course we still need to fix the root cause (at the least, by ignoring the .hash section if the entry size doesn't match).

The fix for PR47681 (s390 specific) is independent from the crash (all platforms), so it should be fixed separatelly.
I'll am going to prepare a follow-up to fix the PR47681 after landing this.

Oct 1 2020, 4:07 AM · Restricted Project
uweigand added a comment to D88561: [llvm-readobj] - Fix possible crashes related to dumping gnu hash symbols..

I think the handling of the GNU hash table is actually already fully correct. The crash (or error message when using this patch) is simply a side effect of the fact that size of the DynSymRegion was clobbered here (near the end of ELFDumper<ELFT>::parseDynamicTable()):

DynSymRegion->Size = HashTable->nchain * DynSymRegion->EntSize;

This in turn is because HashTable->nchain (like all of HashTable) is just incorrect on s390x at the moment, as discussed in https://bugs.llvm.org/show_bug.cgi?id=47681

That is true for you executable. But this patch fixes a bit different case. Here I am creating the .gnu.hash table with a broken value in the buckets array.
Currently with the test case provided we crash an all platforms at the same place where your executable crashes too.
So with this patch we fix the crash, but not the reason of PR47681, which is s390x specific.

Oct 1 2020, 2:54 AM · Restricted Project
uweigand added inline comments to D88599: [SystemZ][ZOS] Porting pthread_t related functionality within libc++ to z/OS.
Oct 1 2020, 2:28 AM · Restricted Project
uweigand added inline comments to D88561: [llvm-readobj] - Fix possible crashes related to dumping gnu hash symbols..
Oct 1 2020, 1:38 AM · Restricted Project

Sep 30 2020

uweigand added a comment to D88561: [llvm-readobj] - Fix possible crashes related to dumping gnu hash symbols..

I think the handling of the GNU hash table is actually already fully correct. The crash (or error message when using this patch) is simply a side effect of the fact that size of the DynSymRegion was clobbered here (near the end of ELFDumper<ELFT>::parseDynamicTable()):

Sep 30 2020, 10:44 AM · Restricted Project

Sep 29 2020

uweigand requested review of D88479: [LLVM 11] Add SystemZ changes to release notes.
Sep 29 2020, 5:00 AM · Restricted Project
uweigand accepted D87510: [SystemZ] Don't emit PC-relative memory accesses to unaligned (packed) symbols..

LGTM now, thanks!

Sep 29 2020, 4:31 AM · Restricted Project

Sep 28 2020

uweigand added inline comments to D87510: [SystemZ] Don't emit PC-relative memory accesses to unaligned (packed) symbols..
Sep 28 2020, 9:26 AM · Restricted Project

Sep 25 2020

uweigand accepted D87988: [SystemZ] Optimize bcmp calls (PR47420).

LGTM as well.

Sep 25 2020, 7:10 AM · Restricted Project

Sep 15 2020

uweigand accepted D87390: [PowerPC] Pass nofpexcept flag to custom lowered constrained ops.

This LGTM, thanks!

Sep 15 2020, 9:39 AM · Restricted Project

Sep 11 2020

uweigand added inline comments to D87510: [SystemZ] Don't emit PC-relative memory accesses to unaligned (packed) symbols..
Sep 11 2020, 7:04 AM · Restricted Project

Sep 9 2020

uweigand committed rG1a25133bcdfe: [DAGCombine] Skip re-visiting EntryToken to avoid compile time explosion (authored by uweigand).
[DAGCombine] Skip re-visiting EntryToken to avoid compile time explosion
Sep 9 2020, 10:14 AM
uweigand closed D86963: [DAGCombine] Skip re-visiting EntryToken to avoid compile time explosion.
Sep 9 2020, 10:14 AM · Restricted Project
uweigand added a comment to D86963: [DAGCombine] Skip re-visiting EntryToken to avoid compile time explosion.

I'd like to make some progress on this soon, given that this still causes every LNT run on the SystemZ build bot to fail ...

Sep 9 2020, 9:03 AM · Restricted Project
uweigand added a comment to D86963: [DAGCombine] Skip re-visiting EntryToken to avoid compile time explosion.

Ping.

Sep 9 2020, 8:55 AM · Restricted Project

Sep 8 2020

uweigand accepted D87222: [PowerPC] [FPEnv] Disable strict FP mutation by default for PowerPC.

We're finally there, great :-) LGTM.

Sep 8 2020, 7:03 AM · Restricted Project
uweigand accepted D87220: [PowerPC] Fix STRICT_FRINT/STRICT_FNEARBYINT lowering.

Makes sense to me. As an aside, this code:

Sep 8 2020, 7:01 AM · Restricted Project, Restricted Project
uweigand accepted D86268: [DAGTypeLegalizer] Handle ZERO_EXTEND of promoted integer in WidenVecRes_Convert..

This LGTM now. Thanks!

Sep 8 2020, 6:03 AM · Restricted Project

Sep 4 2020

uweigand accepted D86605: [PowerPC] Expand constrained ppc_fp128 to i32 conversion.

LGTM now, thanks!

Sep 4 2020, 10:45 AM · Restricted Project
uweigand added a comment to D87130: [SelectionDAGBuilder] Remember to copy the FMF flags in visitBinary()..

I think this makes sense to me, but I want to point out that this partially reverts the commit https://reviews.llvm.org/D46854. I guess there may be other parts of this commit that should be reverted?

The other thing that was removed by that commit was the propagation of the NoNaNs flag from the experimental_vector_reduce_fmax (/fmin) intrinsic to the replacing VECREDUCE_FMAX (/FMIN) node, but I am not sure why...

Sep 4 2020, 9:52 AM · Restricted Project
uweigand added inline comments to D86605: [PowerPC] Expand constrained ppc_fp128 to i32 conversion.
Sep 4 2020, 9:46 AM · Restricted Project
uweigand added inline comments to D87115: [FPEnv][X86][SystemZ] Use different algorithms for i64->double uint_to_fp under strictfp to avoid producing -0.0 when rounding toward negative infinity.
Sep 4 2020, 9:44 AM · Restricted Project
uweigand added inline comments to D86605: [PowerPC] Expand constrained ppc_fp128 to i32 conversion.
Sep 4 2020, 3:52 AM · Restricted Project
uweigand added a comment to D87130: [SelectionDAGBuilder] Remember to copy the FMF flags in visitBinary()..

I think this makes sense to me, but I want to point out that this partially reverts the commit https://reviews.llvm.org/D46854. I guess there may be other parts of this commit that should be reverted?

Sep 4 2020, 3:39 AM · Restricted Project
uweigand added inline comments to D87115: [FPEnv][X86][SystemZ] Use different algorithms for i64->double uint_to_fp under strictfp to avoid producing -0.0 when rounding toward negative infinity.
Sep 4 2020, 3:32 AM · Restricted Project