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] Optimize SELECT CASE for character length 1 [fwd: tobias.burnus@physik.fu-berlin.de]


(I pressed the wrong key and only replied to Jakub.)

On Thu, Jul 15, 2010 at 11:48:15AM +0200, Jakub Jelinek wrote:
> > Thus, d->low/d->high shall be a constant expression (or NULL).
> 
> I wasn't 100% sure, whether constant-expr e.g. can't include
> an elemental function on string literal or something similar.

Constant means something which the front end (simplify expr) can
reduce to a simple number or string literal. (F2003 called this
initialization expression.) In order to make this possible, only
intrinsic functions are allowed, cf. "7.1.12 Constant expression";
thus in trans*.c this should be a simple constant string (literal).


> > Shouldn't this be
> > +                 if (i > 1)
> > +                   break;
> > rather than
> > +                 if (i != d->low->value.character.length)
> > +                   break;
> 
> No, i == d->low->value.character.length is when some character is
> followed only by spaces, and that's exactly the only case which is
> optimized.  if i > 1 means the second character was space, nothing else.

Oh, misread the loop. I was somehow traversing backwards but the loop
went forward. Sorry for misreading.


> > In both loops as the value can never be matched by a single character.
> 
> True, in this case yes.  I was thinking about the general case ("ab":"cd")
> something case ("ce":) something else
> which, while solvable, would be harder.  For the above the question is just
> if no problems will be with some potentially unreachable code.

I am not sure about your last sentence, but one could actually warn with
-Wunreachable-code - something which is not possible with version using the
library call.

(On the other hand, the number of codes which actually uses length > 1 case
 selectors is rather small; thus, I don't know whether one really needs to
 optimize this case.)


> > --- gcc/testsuite/gfortran.dg/select_char_2.f90.jj	2010-07-14 22:01:24.000000000 +0200
> > +++ gcc/testsuite/gfortran.dg/select_char_2.f90	2010-07-14 22:00:23.000000000 +0200
> > 
> > Shouldn't this be a run test and have a tree-dump check that select case
> > is not done via a library call? Or at least the latter?
> 
> It was meant to be a run test, forgot dg-do there apparently.
> For a tree-dump test, I guess we'd need another testcase with dg-do compile.

Why? -fdump-tree-original plus something along the following lines should be
possible and sufficient, shouldn't it?

! { dg-final { scan-tree-dump-times "_gfortran_select_..." 0 "original" } }
! { dg-final { cleanup-tree-dump "original" } }


Tobias

----- End forwarded message -----


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