This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: target register load optimizations (Was: Re: Porting gcc for F-CPU without direct JMP)


Stephen Clarke wrote:
> I would expect that in the current FSF gcc sources, you can use the generic
> execution frequency information, rather than the loop-depth based
> frequency estimation we originally had?    This would give
> profile-directed placement of the target register loads (assuming
> the profiling feedback option is available on the target).

Yes, that's a nice extra project.  However, unless you already have code
for this, I'd like to focus first on getting the interfaces right.

I can imagine  you put the first target register optimization pass before
jump2 so that the number of branch targets isn't increased too much by
cross jumping?

But I can't see why you would want to run the second pass just before
ifconvert - isn't it better to move it after ifconvert?

With respect to the macros, I suppose we should just keep it simple
for now; if we want to change it later, that shouldn't be too difficult,
as the number of ports that use it is limited, and the definitions
simple.

So we can have just one macro:

TARGET_OPTIMIZE_TARGET_REGISTER_CLASS

with a corresponding enum reg_class (*)(void) member for struct
gcc_target.

Or should we avoid the dependency on enum reg_class by
- pro-forma returning an integer?
- use an old-style gcc target macro?

If / when this optimization is enabled is controlled by
flag_optimize_target_registers and flag_optimize_target_registers_2,
which are set by the target-independent code depending on optimization
and can be overridden by tm.h in OPTIMIZATION_OPTIONS and by the
user with -f{,no}optimize-target-registers{,-2} .

If this code makes it into 3.3, we can disable it by default; for
3.4, it should be enabled by default (of course the actual call is not
compiled into the compiler if OPTIMIZE_TARGET_REGISTER_CLASS is not
defined).  I suppose just enabling the later pass would be the more
conservative setting, and thus suitable for the target-indpendent default;
we can override this in sh.h:OPTIMIZATION_OPTIONS.
		
-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]