Need help with match.pd crash

[Michael Collison]

I am trying to improve code generation for coremark to match a recent 
improvement that was made in LLVM.


I added the following transformation to match.pd which attempts to 
replace a branch with straight line code:


/* (cond (and (x , 0x1) == 0), y, (z ^ y) ) -> (-(and (x , 0x1)) & z ) ^ 
y */

(simplify
    (cond (eq (bit_and @0 integer_onep@1)
             integer_zerop)
 @2
 (bit_xor:c @3 @2))
    (bit_xor (bit_and (negate (bit_and @0 @1)) @3) @2))

I get a internal error, but in stepping through the debugger I can see 
the pattern matches, but fails when when it tries to further simplify 
and match another pattern in match.pd:


/* x & C -> x if we know that x & ~C == 0.  */
#if GIMPLE
(simplify
 (bit_and SSA_NAME@0 INTEGER_CST@1)
 (if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
  && wi::bit_and_not (get_nonzero_bits (@0), wi::to_wide (@1)) == 0)
  @0))
#endif

The crash occurs in wi::bit_and_not. Before digging further I want to 
ask if there is a problem with the way I wrote the transformation?

Debugging var-tracking problem

[Michael Collison]

Folks,

I am working on a bug in variable tracking:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61033

GCC is looping infinitely in attempting to solve a data flow problem in 
vt_find_locations. My working theory is that compute_bb_dataflow is 
incorrectly asserting some value has changed when it has not. I have 
reduced my case to a candidate set of basic blocks and a (candidate) RTL 
location this is continually removed/added. The rtl location is:


dataflow difference found: removal of:
 name: D#255
   offset 0
 (mem/f/c:SI (value/u:SI 106:3955 @0x22cb2f8/0x23424a0) [3 
result.d+0 S4 A32])


I understand that the argument to 'VALUE" is a cselib_val_struct but I 
don't know how to map this back to a insn that is causing the problem. 
Any thoughts on how I might debug thus further?


Regards,

Michael Collison
michael.colli...@linaro.org