Propagation of pointer alignment information

Propagation of pointer alignment information

[Richard Earnshaw]

Egcs maintains some information about the alignment of pointer registers 
using the REGNO_POINTER_ALIGN macro, which can then be used by back-ends 
to produce more efficient code sequences than might be otherwise possible. 
 Unfortunately, this can often cause some dodgy code to break, 
particularly when casting is used to break the type system.  A particular 
case I'm running in to on the ARM is when an int* is cast to a short* and 
then dereferenced.  If the int* really was correctly aligned, then there 
is no problem, but the dodgy code (ghostscript in fact) is putting a 
short* into the int* when passing it to a function; the int* is then cast 
back to a short* before being dereferenced, but the compiler is 
remembering the original "alignment" of the int*.

Would it be reasonable to make the compiler not propagate alignment 
through a cast?  This would still leave the case where the alignment is 
derived from the layout of a struct.

Example code...

int foo(int *a)
{
  puts("Hello");
  return *(short *)a;
}

int main()
{
  short x[4];


  x[0] = 1;
  x[1] = 3;
  x[2] = 5;
  x[3] = 6;
  printf("%d\n", foo((int *)(x+0)));
  printf("%d\n", foo((int *)(x+1)));
}

which on an ARM with -O2 gives the unexpected

Hello
1
Hello
6

Re: Propagation of pointer alignment information

[Joern Rennecke]

> Would it be reasonable to make the compiler not propagate alignment 
> through a cast?  This would still leave the case where the alignment is 
> derived from the layout of a struct.

I don't think that should be the default.  If this is really needed
for some programs, you could make a new invokation options that 
disables these alignment propagations, just like -fvolatile caters
for programs that really mean volatile even they don't say so.

Re: Propagation of pointer alignment information

[Richard Earnshaw]

> > Would it be reasonable to make the compiler not propagate alignment 
> > through a cast?  This would still leave the case where the alignment is 
> > derived from the layout of a struct.
> 
> I don't think that should be the default.  If this is really needed
> for some programs, you could make a new invokation options that 
> disables these alignment propagations, just like -fvolatile caters
> for programs that really mean volatile even they don't say so.

This makes sense, but taking that route, I think it then makes sense when 
the flag is unset to then turn off all alignment assumptions that are 
inferred via REGNO_POINTER_ALIGN.  The patch below does this.

Jeff, is the following patch OK to install?

<date>  Richard Earnshaw (rearnsha@arm.com)

	* toplev.c (flag_infer_align): New flag.
	(lang_independent_options): Add -finfer-align to list of flags.
	(main): Turn it on when optimizing.
	* flags.h (flag_infer_align): Declare it.
	* emit-rtl.c (mark_reg_pointer): Only set REGNO_POINTER_ALIGN if
	flag_infer_align.
	(init_emit): Note that alignments of stack and frame regs are well
	known, even if flag_infer_align is unset.
	* invoke.texi: Document -finfer-align.

Re: Propagation of pointer alignment information

[Jeffrey A Law]

  In message < 199812161354.NAA04076@sun52.NIS.cambridge >you write:
  > This makes sense, but taking that route, I think it then makes sense when 
  > the flag is unset to then turn off all alignment assumptions that are 
  > inferred via REGNO_POINTER_ALIGN.  The patch below does this.
  > 
  > Jeff, is the following patch OK to install?
  > 
  > <date>  Richard Earnshaw (rearnsha@arm.com)
  > 
  > 	* toplev.c (flag_infer_align): New flag.
  > 	(lang_independent_options): Add -finfer-align to list of flags.
  > 	(main): Turn it on when optimizing.
  > 	* flags.h (flag_infer_align): Declare it.
  > 	* emit-rtl.c (mark_reg_pointer): Only set REGNO_POINTER_ALIGN if
  > 	flag_infer_align.
  > 	(init_emit): Note that alignments of stack and frame regs are well
  > 	known, even if flag_infer_align is unset.
  > 	* invoke.texi: Document -finfer-align.
Implementation seems fine.

I'm not a big fan of having lots of options to work around bad user code. 

I'm willing to go along with this patch if you think this problem is important
enough to warrant adding the change.  But we shouldn't make a habit of hacking
the compiler to work around bugs in user code.

jeff

Re: Propagation of pointer alignment information

[Richard Henderson]

On Wed, Dec 16, 1998 at 11:06:45PM -0700, Jeffrey A Law wrote:
> I'm not a big fan of having lots of options to work around bad user code. 

Neither am I.

> I'm willing to go along with this patch if you think this problem is important
> enough to warrant adding the change.  But we shouldn't make a habit of hacking
> the compiler to work around bugs in user code.

If the only problem code you've seen is for Ghostscript, I'm not
sure I'd bother.  I hacked up the source to make it work for the
Alpha.  The key to the hack is that gcc will propogate through a
cast, but not through an assignment to a properly typed variable.

+#define PACKED(pref)  ({ const ushort *_T_ = (const ushort *)(pref); _T_; })

Does the trick.  I can pass the whole patch along if you are interested.



r~