On Thu, 2 Dec 2010, Joern Rennecke wrote:
> The intended use for inline hooks would be macros that we are currently
> reluctant to fully convert to hooks because of concerns about performance.
Those can clearly be low priority. Convert the others, see after that
what LTO is like for hook devirt
Quoting "Joseph S. Myers" :
I think we want to move *away* from inline functions in headers and
towards link-time inlining, in the interests of modularity: if one
component of GCC cannot see the internals of another component at compile
time, it cannot use them but must use the actual interface
I think we want to move *away* from inline functions in headers and
towards link-time inlining, in the interests of modularity: if one
component of GCC cannot see the internals of another component at compile
time, it cannot use them but must use the actual interface of that
component, but inli
Joern Rennecke writes:
> For the rtl passes, architecture target macros are not much of an issue
> with regards to executable code modularity: since the rtl passes are
> deeply interwoven with the insn-*.c files, we might as well compile one
> specialized copy of the rtl passes for each target ar
For the rtl passes, architecture target macros are not much of an issue
with regards to executable code modularity: since the rtl passes are
deeply interwoven with the insn-*.c files, we might as well compile one
specialized copy of the rtl passes for each target architecture.
Another argument ag
