the actual destructive merging.
-Mat
Steven Bosscher writes:
> On Mon, Apr 12, 2010 at 6:57 PM, Mat Hostetter 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 data
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
ali
I've implemented some special insns that access hardware resources.
These insns have side effects so they cannot be deleted or reordered
with respect to each other. I made them UNSPEC_VOLATILE, which
generates correct code. Unfortunately, performance is poor.
The problem is that UNSPEC_VOLATILE
Adam Nemet 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 yield redu
Adam Nemet writes:
> Ian Lance Taylor writes:
> > Mat Hostetter 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:
>
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 impleme
