Re: [PATCH] PR opt/6627: New target macro MINIMUM_FUNCTION_BOUNDARY

[Roger Sayle <roger at eyesopen dot com>]

On Sun, 29 Sep 2002, Richard Henderson wrote:
> On Sat, Sep 28, 2002 at 09:47:18PM -0600, Roger Sayle wrote:
> This is incorrect.  FUNCTION_BOUNDARY is the _known_ alignment
> of a function.  This is used during optimization.
>
> I don't think you need a new target macro.  The ability to
> override the user's align_function setting is enough.  If
>   TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_pfn
> then align_function must be >= 2.

The problem is that TARGET_PTRMEMFUNC_VBIT_LOCATION is defined
in terms of FUNCTION_BOUNDARY [line 472 of defaults.h].

Infact this is the only other use of FUNCTION_BOUNDARY in CVS,
so this would contradict your claim that this is used in
optimizations.

Consider also the case that GCC 3.x can be used to link against
objects generated by other vendors compilers (Intel, Microsoft, etc..)
and even 2.9x versions of GCC that can and do omit padding when aligning
functions. If you remember back to the days of CP/M and MSDOS, the
operating system entry point is at address 0005, and hence unaligned.
Indeed on any Windows machine today, type "debug" in the MSDOS window
and type "u0005" to see that this entry point is still supported
by Microsoft.

Hence the correct value for _known_ alignment on IA-32 is one
byte.  Unfortunately, the current C++ ABI on IA-32 mandates
atleast two bytes.

Some confussion may come from my macro naming.  We really require
two macros, MINIMUM_FUNCTION_BOUNDARY and CPLUSPLUS_FUNCTION_BOUNDARY.
Yes, FUNCTION_BOUNDARY was intended and is documented to mean
MINIMUM_FUNCTION_BOUNDARY, but its meaning has been corrupted to its
current use as CPLUSPLUS_FUNCTION_BOUNDARY or DEFAULT_FUNCTION_BOUNDARY.
It was much easier to reflect the de facto usage in the documentation
that rename this macro in each of the backends.

Roger
--