uweigand (Ulrich Weigand)
User

Projects

User does not belong to any projects.

User Details

User Since
Apr 14 2013, 11:48 AM (240 w, 3 d)

Recent Activity

Tue, Nov 14

uweigand committed rL318187: [SystemZ] Do not crash when selecting an OR of two constants.
[SystemZ] Do not crash when selecting an OR of two constants
Tue, Nov 14, 12:03 PM
uweigand committed rL318177: [SystemZ] Fix invalid codegen using RISBMux on out-of-range bits.
[SystemZ] Fix invalid codegen using RISBMux on out-of-range bits
Tue, Nov 14, 11:22 AM

Thu, Nov 9

uweigand committed rL317807: [SystemZ] Add support for the "o" inline asm constraint.
[SystemZ] Add support for the "o" inline asm constraint
Thu, Nov 9, 8:32 AM
uweigand added inline comments to D36795: [SystemZ] Increase number of LOCRs emitted by passing regalloc hints.
Thu, Nov 9, 7:39 AM
uweigand added a comment to D36795: [SystemZ] Increase number of LOCRs emitted by passing regalloc hints.

See two minor inline comments. Otherwise, this now LGTM. Thanks!

Thu, Nov 9, 7:03 AM

Wed, Oct 25

uweigand added a comment to D38128: Handle COPYs of physregs better (regalloc hints).

Right. Always coalescing with the copy source of course extends the live range of the source, and thus increases overall register pressure. So it's not a good idea to do this unconditionally.

Wed, Oct 25, 5:00 AM

Tue, Oct 24

uweigand added a comment to D38894: [RFC][Tablegen] Add CCIfSplitFrom and CCPassIndirectBySamePointer Calling Convention Interfaces.

Well, the special handling of i128 arguments as such is certainly needed on SystemZ, this is why I added it in the first place in rev. 261325.

Tue, Oct 24, 8:20 AM
uweigand added a comment to D38128: Handle COPYs of physregs better (regalloc hints).

Would any of these be an improvement worth trying, then?

(1) If the source phys-reg is contained in the regclass of an immediately following instruction using the vreg, then increase the priority of the hint of that phys-reg.
(2) A simpler alternative would be to simply prefer phys-reg sources more than phys-reg dest-regs (if weight is equal). That would catch all the cases of (1).

Tue, Oct 24, 5:22 AM
uweigand added a comment to D38128: Handle COPYs of physregs better (regalloc hints).

Not sure if it is clear that coalescing with %R8 is generally better than %R0.

What do you mean, it isn't clear? Is the performance problem not clear? Or do you mean you're not sure how to detect this situation when you're sorting the hints?

I guess given your initial wording ("not great"), I was not sure if this is general and serious enough so that we really want to add an additional heuristic like "COPY to compare" on top of the sorting by weight. I suppose then there should be a flag like HasCompareUser which is then the tie-breaker when the weight is the same, or?

Tue, Oct 24, 2:31 AM

Oct 17 2017

uweigand added a comment to D38894: [RFC][Tablegen] Add CCIfSplitFrom and CCPassIndirectBySamePointer Calling Convention Interfaces.

The SystemZ parts LGTM. I agree that it's much preferable to have this handled in common code than in the back end ...

Oct 17 2017, 4:23 AM

Oct 6 2017

uweigand accepted D37977: SystemZ: mischeduler enabled.

OK, this now looks all good to me, thanks!

Oct 6 2017, 5:04 AM

Oct 4 2017

uweigand added a comment to D37977: SystemZ: mischeduler enabled.

Have you looked into what's going on with the vec-cmp-cmp-logic-select.ll and vec-cmpsel.ll test cases? I see several of the tests now adding spill/reload code when they didn't before -- ideally this shouldn't happen if the misched does proper register pressure analysis ...

Oct 4 2017, 7:17 AM

Sep 29 2017

uweigand accepted D37899: [SystemZ] Implement shouldCoalesce() to help regalloc to avoid running out of registers with GR128 regs.

Given that:

  • Quentin approved the interface change
  • The SystemZ parts now look good to me
  • We have performance runs confirming this does not introduce regressions
Sep 29 2017, 5:22 AM
uweigand added a comment to D38215: [SelectionDAG] Fix ATOMIC_CMP_SWAP_WITH_SUCCESS expansion.

Note that as of r314428 I've switched the SystemZ back-end to use a custom expander for ATOMIC_CMP_SWAP_WITH_SUCCESS, which makes use of the condition code value set by the compare-and-swap hardware instruction to completely omit any extra comparison.

Sep 29 2017, 2:29 AM

Sep 28 2017

uweigand committed rL314465: [SystemZ] Fix fall-out from r314428.
[SystemZ] Fix fall-out from r314428
Sep 28 2017, 3:10 PM
uweigand committed rL314428: [SystemZ] Custom-expand ATOMIC_CMP_AND_SWAP_WITH_SUCCESS.
[SystemZ] Custom-expand ATOMIC_CMP_AND_SWAP_WITH_SUCCESS
Sep 28 2017, 9:24 AM
uweigand added a comment to D38128: Handle COPYs of physregs better (regalloc hints).

Sorry - with the update this fails again, so no update...
Should we make a point to try to handle this somehow?

Sep 28 2017, 7:57 AM

Sep 27 2017

uweigand added a comment to D38128: Handle COPYs of physregs better (regalloc hints).

I have attempted to extend the common code instead to handle this. While doing so, the multiple hints have become sorted by weight as requested.

Sep 27 2017, 4:50 AM
uweigand added a comment to D37899: [SystemZ] Implement shouldCoalesce() to help regalloc to avoid running out of registers with GR128 regs.

Considering other types of code with more heavy use of GR128, would we perhaps want to also give a count for a virtual register definition of a GR128? That should avoid being too optimistic when several of these overlap.

Sep 27 2017, 4:26 AM

Sep 25 2017

uweigand added a comment to D37899: [SystemZ] Implement shouldCoalesce() to help regalloc to avoid running out of registers with GR128 regs.

Not sure about the magic numbers -- does it matter whether we stop after 10 MIs? What kind of compile-time performance impact would it have to scan the whole range?

I don't know, I just thought that we basically wanted to at least handle the type of case where there is a GR128 op and then some subreg COPY(s) very close. My reason for having the instruction limit is that we can't know the register pressure, but it seems safe to think that tiny live ranges checked in this way could be coalesced.

Sep 25 2017, 8:16 AM
uweigand added a comment to D37899: [SystemZ] Implement shouldCoalesce() to help regalloc to avoid running out of registers with GR128 regs.

Patch updated.

I looked into making i128 legal when I recently added the 128-bit atomics, but in the end decided against it. Not only would it be a lot of work (since you basically would have to reimplement all the operations on i128 that are currently handled by common code), but it is not clear that we actually always want it.

I thought one could get away with adding calling setOperationAction(..., i128, Expand) on all operations that we do not support...

Sep 25 2017, 5:30 AM
uweigand created D38215: [SelectionDAG] Fix ATOMIC_CMP_SWAP_WITH_SUCCESS expansion.
Sep 25 2017, 5:02 AM

Sep 22 2017

uweigand added a comment to D37899: [SystemZ] Implement shouldCoalesce() to help regalloc to avoid running out of registers with GR128 regs.

I looked into making i128 legal when I recently added the 128-bit atomics, but in the end decided against it. Not only would it be a lot of work (since you basically would have to reimplement all the operations on i128 that are currently handled by common code), but it is not clear that we actually always want it.

Sep 22 2017, 6:29 AM
uweigand committed rL313977: [zorg] Add email notification for new SystemZ builders.
[zorg] Add email notification for new SystemZ builders
Sep 22 2017, 4:32 AM
uweigand closed D33777: [ZORG] Add email notification for new SystemZ builders by committing rL313977: [zorg] Add email notification for new SystemZ builders.
Sep 22 2017, 4:32 AM · Restricted Project

Sep 21 2017

uweigand added a comment to D38058: [llvm-readobj] Teach readobj to output .res (WindowsResource)..

Looks like this broke the s390x build bots:
http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/11433/steps/ninja%20check%201/logs/FAIL%3A%20LLVM%3A%3Ares-resources.test

Sep 21 2017, 9:47 AM
uweigand added a comment to D38128: Handle COPYs of physregs better (regalloc hints).

This doesn't look in any way target-specific, so I'm wondering why common code doesn't already do that. It seems there is already support for extracting hints from copies in calculateSpillWeightAndHint, why is this not working here?

Sep 21 2017, 9:41 AM
uweigand accepted D38076: SystemZ: improved optimizeCompareZero().

LGTM, thanks!

Sep 21 2017, 6:27 AM
uweigand added a comment to D38076: SystemZ: improved optimizeCompareZero().

Test case reduced.

Also found out that the first check in resultTests() must not be used in a forward search, as in that case the reg is actually taking on a new value in between the compare and the CC-user. For this purpse, I added the 'BeforeCompare' parameter to the function.

Sep 21 2017, 5:47 AM

Sep 20 2017

uweigand added a comment to D36795: [SystemZ] Increase number of LOCRs emitted by passing regalloc hints.

Looks basically good to me, just a couple of cosmetic comments inline.

Sep 20 2017, 10:17 AM
uweigand added a comment to D38076: SystemZ: improved optimizeCompareZero().

The code change looks good to me, but please try to simplify the .mir test case following the suggestions outlined here: https://llvm.org/docs/MIRLangRef.html#simplifying-mir-files

Sep 20 2017, 10:07 AM

Sep 19 2017

uweigand committed rL313669: [SystemZ] Fix truncstore + bswap codegen bug.
[SystemZ] Fix truncstore + bswap codegen bug
Sep 19 2017, 1:51 PM
uweigand added a comment to D37899: [SystemZ] Implement shouldCoalesce() to help regalloc to avoid running out of registers with GR128 regs.

Test cases updated. As expected, there are now more register moves whenever the coalescer is disabled by this patch.

Sep 19 2017, 8:48 AM

Sep 18 2017

uweigand added a comment to D37977: SystemZ: mischeduler enabled.

Hmm. Some of those changes look like regressions, we should try to at least understand why this happens. Maybe there's a simple way to fix those again.

Sep 18 2017, 8:20 AM

Sep 17 2017

uweigand committed rL313480: [compiler-rt] Fix build break after r313277 on s390x.
[compiler-rt] Fix build break after r313277 on s390x
Sep 17 2017, 2:40 AM

Sep 15 2017

uweigand added a comment to D37898: [TargetLowering] Correctly track NumFixedArgs field of CallLoweringInfo.

As far as SystemZ is concerned, this change should be safe. In our ABI only vector arguments are affected by the IsFixed flags, and there shouldn't be any libcalls with vector arguments.

Sep 15 2017, 10:09 AM
uweigand added a comment to D37899: [SystemZ] Implement shouldCoalesce() to help regalloc to avoid running out of registers with GR128 regs.

Thanks for trying this suggestion! See a couple of inline comments.

Sep 15 2017, 9:31 AM

Aug 21 2017

uweigand added a comment to D36795: [SystemZ] Increase number of LOCRs emitted by passing regalloc hints.

I think that to handle those cases we would have to constrain regclasses somehow after coalescing.

Aug 21 2017, 7:32 AM

Aug 18 2017

uweigand added a comment to D36795: [SystemZ] Increase number of LOCRs emitted by passing regalloc hints.

The getRegAllocationHints implementation makes sense to me. However, I'm wondering if we shouldn't also check for the *destination* register -- you only force one source register to the same class as the other source register, but I think we should check whether *any* of the three registers is already allocated, and then always force the other two to the same class.

I tried this (see updated patch below), but found that it gave the identical results (with or without the DestMO lines which I commented out). My guess is that the the TwoAddress pass is already doing this job in processTiedPairs() by

Aug 18 2017, 3:39 AM

Aug 17 2017

uweigand added a comment to D36795: [SystemZ] Increase number of LOCRs emitted by passing regalloc hints.

Oh, and just comment on this:

Aug 17 2017, 7:32 AM
uweigand added a comment to D36795: [SystemZ] Increase number of LOCRs emitted by passing regalloc hints.

The getRegAllocationHints implementation makes sense to me. However, I'm wondering if we shouldn't also check for the *destination* register -- you only force one source register to the same class as the other source register, but I think we should check whether *any* of the three registers is already allocated, and then always force the other two to the same class.

Aug 17 2017, 7:28 AM

Aug 4 2017

uweigand committed rL310094: [SystemZ] Add support for 128-bit atomic load/store/cmpxchg.
[SystemZ] Add support for 128-bit atomic load/store/cmpxchg
Aug 4 2017, 11:58 AM
uweigand committed rL310093: [SystemZ] Eliminate unnecessary serialization operations.
[SystemZ] Eliminate unnecessary serialization operations
Aug 4 2017, 11:54 AM

Aug 2 2017

uweigand added a comment to D36173: [InstSimplify] Perform known-bits analysis in SimplifyAndInst.

Yes, this benefits a real workload. This happens when the improved SimplifyAndInst now simplifies a partial result, which then allows *further* simplification in InstSimplify, in my case in ThreadBinOpOverPHI. This latter simplification doesn't seem to be done anywhere else.

Aug 2 2017, 10:21 AM
uweigand added a comment to D36172: [InstCombine] Improve profitability check for folding PHI args.
Aug 2 2017, 9:04 AM
uweigand added a comment to D36172: [InstCombine] Improve profitability check for folding PHI args.

The testcase is extracted from a real-word program. On that program, the transformation (moving some of those operations out of a hot loop) is a significant overall win (about 10% improved performance of the whole program). I agree that this application is a quite special case -- this patch doesn't make much difference to the overall performance of the platform in general.

Aug 2 2017, 8:38 AM
uweigand added a comment to D36173: [InstSimplify] Perform known-bits analysis in SimplifyAndInst.

Sure, it would be possible to add the corresponding transforms to SimplifyOrInst. However, I have been unable to trigger this at all, with any workload I've tried. Should I still add the transforms anyway?

Aug 2 2017, 6:53 AM
uweigand added a comment to D36172: [InstCombine] Improve profitability check for folding PHI args.

Well, I'd be fine with NewGVN doing this transform. But at least right now, it doesn't appear to be doing so -- running the new test case (@phi_multi in phi.ll) through "opt -O2 --enable-newgvn" does not move the zext/or out of the loop. Is this supposed to happen?

Aug 2 2017, 6:12 AM
uweigand added a comment to D35053: Improve post-RA scheduling for SystemZ.

OK, the SystemZ parts look good to me now. Thanks!

Aug 2 2017, 2:01 AM

Aug 1 2017

uweigand updated subscribers of D36173: [InstSimplify] Perform known-bits analysis in SimplifyAndInst.
Aug 1 2017, 1:41 PM
uweigand created D36175: [InstSimplify] Accept more loop-invariant cases in ThreadBinOpOverPHI.
Aug 1 2017, 1:40 PM
uweigand created D36173: [InstSimplify] Perform known-bits analysis in SimplifyAndInst.
Aug 1 2017, 1:31 PM
uweigand created D36172: [InstCombine] Improve profitability check for folding PHI args.
Aug 1 2017, 1:24 PM
uweigand added a comment to D35053: Improve post-RA scheduling for SystemZ.

Thanks! The SystemZ part now looks very reasonable. Just a couple of final, really just cosmetic comments inline.

Aug 1 2017, 4:50 AM

Jul 31 2017

uweigand added inline comments to D35053: Improve post-RA scheduling for SystemZ.
Jul 31 2017, 8:44 AM
uweigand added a comment to D35053: Improve post-RA scheduling for SystemZ.

A couple more comments on the SystemZ parts, see inline comments.

Jul 31 2017, 5:42 AM

Jul 28 2017

uweigand added a comment to D35933: Eliminate TargetTransformInfo::isFoldableMemAccess().

I'm not sure about the common code changes -- what does simply calling isLegalAddressingMode instead of isFoldableMemAccessOffset do to targets that have not yet added support to do instruction-specific checks to the former? I'd assume you'd see performance regressions there.

Maybe this transition should be done on a target-by-target basis.

SystemZ was the only user of isFoldableMemAccessOffset() except for any out-of-tree targets.

Jul 28 2017, 4:46 AM

Jul 27 2017

uweigand added a comment to D35933: Eliminate TargetTransformInfo::isFoldableMemAccess().

The SystemZ part looks correct to me, see the inline comment for a style/readability suggestion.

Jul 27 2017, 6:06 AM

Jul 24 2017

uweigand added a comment to D35053: Improve post-RA scheduling for SystemZ.

It does indeed seem to be necessary to get an explicit guarantee from common code that scheduling happens in a particular order, otherwise our back-end code may silently break if common code logic happens to change in the future.

Jul 24 2017, 8:11 AM

Jul 21 2017

uweigand accepted D35049: LSR tunings for SystemZ, with some minor common code changes.

I agree this isn't perfect. I also noticed this before, and thought this could be possibly refactored but however also noticed the many different overloaded versions of isLegalAddressingMode() and thought that it could wait as a next step, perhaps. RateFormula() currently only checks the fixup instructions for the offsets, so I am not sure this is a trivial change.

Jul 21 2017, 3:06 AM

Jul 20 2017

uweigand added a comment to D35049: LSR tunings for SystemZ, with some minor common code changes.

A few comments/questions, looking only at the SystemZ-specific parts.

Jul 20 2017, 10:59 AM

Jul 17 2017

uweigand committed rL308199: [SystemZ] Add support for IBM z14 processor (3/3).
[SystemZ] Add support for IBM z14 processor (3/3)
Jul 17 2017, 10:48 AM
uweigand committed rL308198: [SystemZ] Add support for IBM z14 processor (2/3).
[SystemZ] Add support for IBM z14 processor (2/3)
Jul 17 2017, 10:47 AM
uweigand committed rL308197: [SystemZ] Add support for IBM z14 processor (1/3).
[SystemZ] Add support for IBM z14 processor (1/3)
Jul 17 2017, 10:46 AM
uweigand committed rL308196: [SystemZ] Add support for IBM z14 processor (3/3).
[SystemZ] Add support for IBM z14 processor (3/3)
Jul 17 2017, 10:45 AM
uweigand committed rL308195: [SystemZ] Add support for IBM z14 processor (2/3).
[SystemZ] Add support for IBM z14 processor (2/3)
Jul 17 2017, 10:43 AM
uweigand committed rL308194: [SystemZ] Add support for IBM z14 processor (1/3).
[SystemZ] Add support for IBM z14 processor (1/3)
Jul 17 2017, 10:41 AM

Jul 5 2017

uweigand committed rL307156: [SystemZ] Simplify handling of ISA revisions.
[SystemZ] Simplify handling of ISA revisions
Jul 5 2017, 6:20 AM
uweigand committed rL307155: [SystemZ] Simplify handling of 128-bit multiply/divide instruction.
[SystemZ] Simplify handling of 128-bit multiply/divide instruction
Jul 5 2017, 6:18 AM
uweigand committed rL307154: [SystemZ] Small cleanups to SystemZScheduleZ13.td.
[SystemZ] Small cleanups to SystemZScheduleZ13.td
Jul 5 2017, 6:15 AM

Jun 30 2017

uweigand committed rL306876: [SystemZ] Add all remaining instructions.
[SystemZ] Add all remaining instructions
Jun 30 2017, 1:44 PM
uweigand committed rL306821: [SystemZ] Add missing high-word facility instructions.
[SystemZ] Add missing high-word facility instructions
Jun 30 2017, 5:56 AM

Jun 26 2017

uweigand committed rL306305: [SystemZ] Fix missing emergency spill slot corner case.
[SystemZ] Fix missing emergency spill slot corner case
Jun 26 2017, 9:50 AM

Jun 23 2017

uweigand committed rL306117: [SystemZ] Remove unnecessary serialization before volatile loads.
[SystemZ] Remove unnecessary serialization before volatile loads
Jun 23 2017, 8:57 AM

Jun 20 2017

uweigand added a comment to D34243: [Sanitizers] Secondary allocator respects allocator_may_return_null=1..

The new test case fails on SystemZ, making all our build bots red.

Jun 20 2017, 10:24 AM

Jun 1 2017

uweigand created D33777: [ZORG] Add email notification for new SystemZ builders.
Jun 1 2017, 7:10 AM · Restricted Project

May 30 2017

uweigand committed rL304203: [SystemZ] Add decimal floating-point instructions.
[SystemZ] Add decimal floating-point instructions
May 30 2017, 3:15 AM
uweigand committed rL304202: [SystemZ] Add hexadecimal floating-point instructions.
[SystemZ] Add hexadecimal floating-point instructions
May 30 2017, 3:13 AM
uweigand committed rL304200: [SystemZ] Add missing assembler/disassembler tests.
[SystemZ] Add missing assembler/disassembler tests
May 30 2017, 3:11 AM

May 29 2017

uweigand accepted D33648: [OpenCL] An error shall occur if any scalar operand has greater rank than the type of the vector element.

Yes, this works for me now. Thanks!

May 29 2017, 9:38 AM
uweigand added a comment to rL303907: Fix bug #28898.

It appears this commit broke the EditlineTestFixture.EditlineReceivesSingleLineText unit test on s390x-linux. The test now simply hangs (hanging the whole test suite execution) ...

May 29 2017, 8:12 AM
uweigand added a comment to D33353: [OpenCL] An error shall occur if any scalar operand has greater rank than the type of the vector element.

The problem is that the new test case you added does not contain a -triple argument in the compile command. This means that the compile targets the native architecture on the build system, whatever this is. Since OpenCL support on different architectures may be different (e.g. some may support the cl_khr_fp64 extension by default while others do not), you see the error only on some build architectures.

May 29 2017, 5:35 AM

May 27 2017

uweigand added a comment to D33502: [ZORG] Add more SystemZ builders.

I've checked the changes in to the zorg SVN repo, but the new builders don't show up on the build bot web page. Is there anything else I need to do here?

May 27 2017, 8:17 AM · Restricted Project
uweigand committed rL304071: [zorg][SystemZ] Upgrade build machine and add builders.
[zorg][SystemZ] Upgrade build machine and add builders
May 27 2017, 6:26 AM
uweigand closed D33502: [ZORG] Add more SystemZ builders by committing rL304071: [zorg][SystemZ] Upgrade build machine and add builders.
May 27 2017, 6:26 AM · Restricted Project

May 26 2017

uweigand added a comment to D33184: [DWARF] - Make collectAddressRanges() return section index in addition to Low/High PC.

This seems to have caused a failure in the SystemZ build bot:
http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/8750

May 26 2017, 10:30 AM
uweigand added a comment to D33353: [OpenCL] An error shall occur if any scalar operand has greater rank than the type of the vector element.

Could you revert Egor's commit, please?

May 26 2017, 8:55 AM
uweigand added a comment to D33353: [OpenCL] An error shall occur if any scalar operand has greater rank than the type of the vector element.

Looks like this causes the build bot to fail on SystemZ:
http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/8741

May 26 2017, 8:21 AM

May 24 2017

uweigand created D33502: [ZORG] Add more SystemZ builders.
May 24 2017, 9:20 AM · Restricted Project
uweigand committed rL303757: [sanitizer] [SystemZ] Update CVE-2016-2143 check for Ubuntu 16.04.
[sanitizer] [SystemZ] Update CVE-2016-2143 check for Ubuntu 16.04
May 24 2017, 8:06 AM
uweigand accepted D32422: LoopVectorizer: let target prefer scalar addressing computations (+ minor improvements in SystemZTTI).

The code LGTM, I do not have more comments on it. I can't say anything about profitability of this algorithm for SystemZ, may be you need additional LGTM from one of SystemZ developers?

May 24 2017, 6:10 AM
uweigand added a comment to D33465: Add build instructions for System Z s390, too..

Can you explain why you want to do this?

May 24 2017, 4:34 AM

May 23 2017

uweigand added a comment to D33402: [RuntimeDyld, PowerPC] Fix check for external symbols when detecting reloction overflow.

It seems that to identify external symbols, we need to check for *either* non-null Value.SymbolName *or* a SymType of Symbol::ST_Unknown.

May 23 2017, 10:05 AM
uweigand committed rL303655: [RuntimeDyld, PowerPC] Fix regression from r303637.
[RuntimeDyld, PowerPC] Fix regression from r303637
May 23 2017, 10:03 AM
uweigand added a comment to D33402: [RuntimeDyld, PowerPC] Fix check for external symbols when detecting reloction overflow.

This seems to have broken some MCJIT test cases on big-endian ppc64 ... I'll have a look.

May 23 2017, 8:53 AM
uweigand committed rL303637: [RuntimeDyld, PowerPC] Fix check for external symbols when detecting reloction….
[RuntimeDyld, PowerPC] Fix check for external symbols when detecting reloction…
May 23 2017, 7:51 AM
uweigand closed D33402: [RuntimeDyld, PowerPC] Fix check for external symbols when detecting reloction overflow by committing rL303637: [RuntimeDyld, PowerPC] Fix check for external symbols when detecting reloction….
May 23 2017, 7:51 AM
uweigand updated the diff for D33402: [RuntimeDyld, PowerPC] Fix check for external symbols when detecting reloction overflow.

Added test case. Note that it is a bit tricky to replicate the exact condition that triggers the bug in a test case. The one attached here seems to fail reliably (before the fix) across different operating system versions on Power, but it still makes a few assumptions (called out in the comments).

May 23 2017, 6:20 AM
uweigand committed rL303632: [RuntimeDyld, PowerPC] Fix relocation detection overflow.
[RuntimeDyld, PowerPC] Fix relocation detection overflow
May 23 2017, 5:44 AM
uweigand closed D33403: [RuntimeDyld, PowerPC] Fix relocation detection overflow by committing rL303632: [RuntimeDyld, PowerPC] Fix relocation detection overflow.
May 23 2017, 5:44 AM