diff options
author | Vasileios Kalintiris <Vasileios.Kalintiris@imgtec.com> | 2015-07-30 11:51:44 +0000 |
---|---|---|
committer | Vasileios Kalintiris <Vasileios.Kalintiris@imgtec.com> | 2015-07-30 11:51:44 +0000 |
commit | 77fb0a3dcf19df35533840e096a26fb7e5e18f9b (patch) | |
tree | 21847c52f1b53404efd68a3152676670d6aea3d2 /clang/lib/Basic/Module.cpp | |
parent | 10e775f4a882ec49e374bbeca567e91547d78312 (diff) | |
download | llvm-77fb0a3dcf19df35533840e096a26fb7e5e18f9b.zip llvm-77fb0a3dcf19df35533840e096a26fb7e5e18f9b.tar.gz llvm-77fb0a3dcf19df35533840e096a26fb7e5e18f9b.tar.bz2 |
[mips][FastISel] Apply only zero-extension to constants prior to their materialization.
Summary:
Previously, we would sign-extend non-boolean negative constants and
zero-extend otherwise. This was problematic for PHI instructions with
negative values that had a type with bitwidth less than that of the
register used for materialization.
More specifically, ComputePHILiveOutRegInfo() assumes the constants
present in a PHI node are zero extended in their container and
afterwards deduces the known bits.
For example, previously we would materialize an i16 -4 with the
following instruction:
addiu $r, $zero, -4
The register would end-up with the 32-bit 2's complement representation
of -4. However, ComputePHILiveOutRegInfo() would generate a constant
with the upper 16-bits set to zero. The SelectionDAG builder would use
that information to generate an AssertZero node that would remove any
subsequent trunc & zero_extend nodes.
In theory, we should modify ComputePHILiveOutRegInfo() to consult
target-specific hooks about the way they prefer to materialize the
given constants. However, git-blame reports that this specific code
has not been touched since 2011 and it seems to be working well for every
target so far.
Reviewers: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11592
llvm-svn: 243636
Diffstat (limited to 'clang/lib/Basic/Module.cpp')
0 files changed, 0 insertions, 0 deletions