This is the mail archive of the gcc-patches@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: [PATCH] support to flip modes in sh mode-switching


Yes, I didn't say that multiple incoming edges can have different available
modes, that would be nonsense effectively. I probably wasn't clear enough on
what I did:

My point is that since avin and avout are related, a global avin property on
a basic block is the intersection of all avouts predecessors. I might assume
that if a BB has the avin property true for a mode value, then this mode
value is known. The first seginfo in the basic block that uses another mode
value will then flip the mode. (and then modes will be flipped for each
local seginfos)

In optimize_mode_switching, antic and comp are set to the mode values, so
the lcm is done on a mode value basis not on the mode entity basis.

I'm sure that there are some refinements possibles with the combined uses of
antic or avout, but I'm missing a test case for now.

For the exception handler problem: are you mentionning the case where we use
a float in a catch block such as:

try {
	foo();	// uses floats can throw
	bar();	// uses doubles can throw
	foo();
}
catch (...)
{
	// needs float mode here
}

I don't know the g++ internals. Is there an edge from all calls (or
instructions if asynchronous exceptions are enabled) that are not nothrow to
the exceptions handlers ?. In which case I will need to run the g++
testsuite as well for validation. The try-catch exception with mode switches
example might be a good candidate for the testsuite if not tested already.

Best Regards,

Christian

In http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01562.html, you wrote:
> Reminder: This patch adds support in the mode-switching pass to switch 
> modes
instead of setting them. That implies that we need to track for every basic
blocks that need a mode setting (see EMIT_MODE_SET) the mode values of the
incoming edges when 'avin' is set. When 'avin' is not set a regular mode
setting sequence must be emitted.

No, please read the PR more carefully.
The normal case is that for every edge that needs a mode setting, we track
if avout of the source block is set.
avin is only interesting for exception handler blocks.

> The improvements for this new patch came after I realized that I 
> didn't have
to carry any mode information on edges.

That is nonsense.  multiple incoming edges can have different available
modes.
That can actually be expected to happen relatively frequently for the edges
going into the first BB of a loop.
If you use the avout from the edge sources, you can optimize these loops; if
you ignore modes on edges, you can't.

> LCL guaranties that a mode will never been reset to the same value it 
> was in
avin (why would it do that if the value is available ?). Furthermore, mode
values are exclusives. I've added a assertion to check this.

exception handlers have to hide their anticipatable mode to LCM, thus you
have to expect this to happen.


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