Closed Quuxplusone closed 6 years ago
Bugzilla Link | PR34859 |
Status | RESOLVED FIXED |
Importance | P enhancement |
Reported by | Jonas Paulsson (paulsson@linux.vnet.ibm.com) |
Reported on | 2017-10-06 00:56:45 -0700 |
Last modified on | 2017-11-14 12:00:52 -0800 |
Version | trunk |
Hardware | PC Linux |
CC | llvm-bugs@lists.llvm.org, paulsson@linux.vnet.ibm.com, uweigand@de.ibm.com |
Fixed by commit(s) | |
Attachments | |
Blocks | |
Blocked by | |
See also |
Note : the commits for this were:
LLVM : e5e1c85 / trunk@314416
clang: 0e1f5c3 / cfe/trunk@314391
Initial selection DAG: BB#0 'main:'
...
t16: i1 = setcc t13, Constant:i16<0>, setne:ch
t17: i64 = zero_extend t16
t18: i64 = or t17, OpaqueConstant:i64<3944173009226982604>
...
=>
Optimized lowered selection DAG: BB#0 'main:'
...
t18: i64 = or Constant:i64<1>, OpaqueConstant:i64<3944173009226982604>
...
I suspect that the SystemZ backend (splitLargeImmediate() is not expecting to
handle an or with two constants?
I am also guessing that the Opaque bit is somehow preventing the DAGCombiner to
constant fold t18. Not sure exactly why...
(In reply to Jonas Paulsson from comment #2)
> Initial selection DAG: BB#0 'main:'
> ...
> t16: i1 = setcc t13, Constant:i16<0>, setne:ch
> t17: i64 = zero_extend t16
> t18: i64 = or t17, OpaqueConstant:i64<3944173009226982604>
> ...
>
> =>
>
> Optimized lowered selection DAG: BB#0 'main:'
> ...
> t18: i64 = or Constant:i64<1>,
> OpaqueConstant:i64<3944173009226982604>
> ...
>
>
> I suspect that the SystemZ backend (splitLargeImmediate() is not expecting
> to handle an or with two constants?
>
> I am also guessing that the Opaque bit is somehow preventing the DAGCombiner
> to constant fold t18. Not sure exactly why...
I believe this is deliberate, since the large constant is reused a second time,
so it may be better to only materialize the large constant once, and then
actually perform an or with 1 to get the second constant, rather than having to
materialize two different large constants.
The back-end should simply leave the OR alone in this case. I'm testing a
patch ...
Should be fixed by r318187.