Is nonoverlapping_memrefs_p wrong for unknown offsets?

2010-04-12 Thread Mat Hostetter
We recently tracked down an aliasing bug in gcc-4.4.3 (found by our TILE-Gx back end, not yet ready to contribute), and we wanted to make sure the fix is right. try_crossjump_bb identifies some common insns in SPEC2000.eon and uses merge_memattrs to merge them. To do so, it has to unify their

Re: Is nonoverlapping_memrefs_p wrong for unknown offsets?

2010-04-12 Thread Mat Hostetter
destructive merging. -Mat Steven Bosscher stevenb@gmail.com writes: On Mon, Apr 12, 2010 at 6:57 PM, Mat Hostetter mhostet...@tilera.com wrote: try_crossjump_bb identifies some common insns in SPEC2000.eon and uses merge_memattrs to merge them.  To do so, it has to unify their aliasing

Re: gen_lowpart called where 'truncate' needed?

2010-02-05 Thread Mat Hostetter
Adam Nemet adambne...@gmail.com writes: I think the right fix is to call convert_to_mode or convert_move in the expansion code which ensure the proper truncation. That would yield correct code, but wouldn't it throw away the fact that the high bits are already known to be zero, and

Re: gen_lowpart called where 'truncate' needed?

2010-02-04 Thread Mat Hostetter
Adam Nemet adambne...@gmail.com writes: Ian Lance Taylor i...@google.com writes: Mat Hostetter mhostet...@tilera.com writes: Since the high bits are already zero, that would be less efficient on most platforms, so guarding it with something like this would probably be smarter

gen_lowpart called where 'truncate' needed?

2010-02-03 Thread Mat Hostetter
I am porting gcc-4.4.3 to TILE-Gx, a 64-bit VLIW RISC. It's gone pretty well so far; most tests work, Linux builds, etc. Thanks for writing such good documentation. This chip, like MIPS64, maintains the invariant that SImode values in DImode registers are always sign-extended. So I have