This is the mail archive of the
mailing list for the GCC project.
RE: [PATCH] support to flip modes in sh mode-switching
- From: Christian BRUEL <christian dot bruel at st dot com>
- To: "'Joern Rennecke'" <amylaar at spamcop dot net>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 22 Dec 2006 21:26:29 +0100
- Subject: 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
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:
foo(); // uses floats can throw
bar(); // uses doubles can throw
// 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.
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
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
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.