Allow SimplifyDemandedBits to peek through ISD::EXTRACT_ELEMENT nodes
Something seems very wrong here. We seem to simply be materializing a pair of constants which isn't what the test case does.
t4: f64,ch = CopyFromReg t0, Register:f64 %1 t2: f64,ch = CopyFromReg t0, Register:f64 %0 t5: ppcf128 = build_pair t4, t2 t18: i128 = bitcast t5 t21: i64 = extract_element t20, Constant:i64<0> t23: i64 = and t21, Constant:i64<-9223372036854775808> ...
And with this change at the same stage, we have:
t4: f64,ch = CopyFromReg t0, Register:f64 %1 t5: ppcf128 = build_pair t4, undef:f64 t18: i128 = bitcast t5 t21: i64 = extract_element t18, Constant:i64<0> t23: i64 = and t21, Constant:i64<-9223372036854775808>
Then type legalization turns t23 into:
t23: i64 = and undef:i64, Constant:i64<-9223372036854775808>
thereby reducing the entire function to:
t14: ch,glue = CopyToReg t0, Register:i64 $x3, Constant:i64<4615908143078047744> t16: ch,glue = CopyToReg t14, Register:i64 $x4, Constant:i64<-4850376798678024192>, t14:1
That is strange - SimplifyDemandedBits does have a tendency to exploit any weaknesses in other combines, maybe the ppc_fp128 handling in DAGCombiner::visitBITCAST is doing something odd?
This test case was added 6 years ago in 325e8d06dcfb32c636ea30c0c5b3ab6bdf020f56. I don't remember why the only test added gets the magnitude from a constant and the sign from a variable.