On Tue, Mar 09, 2010 at 05:25:35PM +0600, Alexey Salmin wrote:
> On Tue, Mar 9, 2010 at 3:58 PM, Basile Starynkevitch
> <bas...@starynkevitch.net> wrote:
> > Hello All,
> >
> > With a recently compiled gcc-trunk on x86-64/linux, I am compiling the
> > folllowing example:
> >
> > #################
> >
> > /* file testmanychar.c */
> > extern void g (int, char *, char *, char *);
> >
> > void
> > f (void)
> > {
> > char x0, x1, x2, x3, x4, x5, x6, x7;
> > /* assuming x0 is word aligned on a x86_64, and variables are bytes in
> > memory, we could clear all the variables in one machine instruction */
> > x0 = x1 = x2 = x3 = x4 = x5 = x6 = x7 = (char) 0;
> > g (10, &x0, &x1, &x2);
> > g (20, &x2, &x3, &x4);
> > g (30, &x4, &x5, &x6);
> > g (40, &x6, &x7, &x0);
> > }
> >
> > #################
> >
> > My intuition was that GCC could store x0 on a 64 bits aligned byte, and x1
> > immediately after, and so one, and clear all the eight bytes at once using
> > a single machine instruction [clearing a 64 bits word].
>
> Thing you're talking about is a kind of vectorization. If you want to
> simplify the vectorizing for the compiler you should store your data
> in arrays instead of separate variables and use loops to process your
> data instead of separate operations.
I knew about vectorization (of which I am not an expert), and I didn't
mention it, because in my view this is not exactly vectorization.
And I don't want to use an array of bytes for that purpose. I want to have a
rather large number of individual variables.
Perhaps I should give more context about this question. This is inside the
MELT branch of GCC, which happens to generate C code (I won't explain again
why, look in the wiki http://gcc.gnu.org/wiki/MiddleEndLispTranslator etc).
In MELT I have a sophisticated pattern matching machinery, and pattern
matching expressions are translated into a complex bunch of C code (which
will be compiled by the C compiler on the host machine, which probably would
be some GCC version).
But I believe I have a design bug in today's implementation translation of
MELT pattern matching (the translator mostly works, except for or
sub-patterns; in the unlikely case the MELT translator fails to translate a
complex pattern matching, it fails "nicely" with a fatal_error. AFAIK, it
does not generate wrong C code.). I am right now working on this bug (by
implementing a new pattern-matcher translator in
gcc-melt-branch/gcc/melt/warmelt-normatch.melt).
The new scheme for patternmatching translation involves having a boolean
flag for each sub-pattern. Each such flag is initially cleared, may be set to
true at most once, and may be tested several times. But I will have a lot of
such flags (several dozens or hundreds). So the block I am considering to
generate.
So basically, I intend to generate a big C block like
typedef char melt_flag_t; /* or perhaps bool */
{
/* typically dozens or even a hundred of cleared variables */
melt_flag_t f0=0, f1=0, f2=0, f3=0, f4=0, f5=0, f6=0, f7=0, f8=0, f9=0;
/* some complex code with conditionals and forward gotos,
where each above flag is set at most once, and may be tested many times */
}
I don't want to use an array, because in some cases (at least with -O3 for
the GCC compiling that generated code, and when the translated pattern-match
is simple enough so that we have only a dozen or two flags, I can imagine
that GCC will optimize that and put some variables in registers, etc..
So I asked myself if GCC can clear efficiently a set of variables
(BTW, this is mandatory in Java), hence my initial question.
In my view, aggregating several small scalar variables inside a larger word
data is not exactly vectorization (my perception of vectorization is that it
is dealing with arrays). But I am not an expert on these issues so I may be
wrong.
Still, my initial question is not that important. Having a hundred of movb
$0... is not a big deal today. But I was a bit surprized that GCC did not
optimize that, since clearing local variables is common in many programs
(and mandatory in Java).
Cheers.
PS. BTW, Zbigniew Chamski & myself will give a talk in Franch about GCC plugins
at Solutions Linux in Paris, march 17th.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
