1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2025-02-01 05:01:59 +01:00

4 Commits

Author SHA1 Message Date
Vlad Tsyrklevich
9f0f005f28 Revert "[InstCombine] try to narrow a truncated load"
This reverts commit bc4a63fd3c29c1a8ce22891bf34ee4dccfef578c, this is a
speculative revert to fix a number of sanitizer bots (like
sanitizer-x86_64-linux-bootstrap-ubsan) that have started to see stage2
compiler crashes, presumably due to a miscompile.

llvm-svn: 367029
2019-07-25 15:37:57 +00:00
Sanjay Patel
6c5079f044 [InstCombine] try to narrow a truncated load
trunc (load X) --> load (bitcast X to narrow type)

We have this transform in DAGCombiner::ReduceLoadWidth(), but the truncated
load pattern can interfere with other instcombine transforms, so I'd like to
allow the fold sooner.

Example:
https://bugs.llvm.org/show_bug.cgi?id=16739
...in that report, we have bitcasts bracketing these ops, so those could get
eliminated too.

We've generally ruled out widening of loads early in IR ( LoadCombine -
http://lists.llvm.org/pipermail/llvm-dev/2016-September/105291.html ), but
that reasoning may not apply to narrowing if we can preserve information
such as the dereferenceable range.

Differential Revision: https://reviews.llvm.org/D64432

llvm-svn: 367011
2019-07-25 12:14:27 +00:00
Sanjay Patel
3c44948bea [InstCombine] add tests for load narrowing; NFC
Baseline results for D64432.

llvm-svn: 366901
2019-07-24 12:44:21 +00:00
Sanjay Patel
7ca6dd8656 [InstCombine] add tests for trunc(load); NFC
I'm not sure if transforming any of these is valid as
a target-independent fold, but we might as well have
a few tests here to confirm or deny our position.

llvm-svn: 365523
2019-07-09 18:06:16 +00:00