This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: How to clean up i386 machine description?
> In addition to outputting many insns, the x86 port relies on reload to clean
> things up. ie, it has predicates which are very general and relies on reload
> to move operands around to make them match the constraints.
Please can you give me simple example? I oftend tend to make this even
worse, so I am probably missing something significant here.
BTW whats about (match_operand "general_operand" "m") reload abuse?
It should solve the problem with communication between integer and fp
registers witch (according to Bernd's opinion) quite small changes to
reload pass. I personally don't know about any other solution introducing
comparable code (for all other ways I've tried I am able
to construct trivial examples generating ugly code). But this is exactly
opposite of what do you suggest.
> The next decision is how to split them up. Is it better to use a define_split
> to have the scheduler break up the complicated insn into simpler insns? Or is
> it better to tighten the predicates and possibly have multiple insns for the
> various conditions? I don't know. It kind of depends on the complexity of the
> pattern you're working with. I don't know the x86 port well enough to make
> suggestions on this one.
I am usually using multiple insns in cases I need to set different scheduling
attributes or constraints. In other cases I am trying to keep then together,
because for example reload sometimes changes registers to constants but
keeps memoized the original insn pattern, so suboptimal code should result.
According to my experience I have much more problems with define_expand
contra define_insn+split sollution. Pros of define_expand is that
it is quite clean and compiler sees rewrote version of pattern and is
able to do lots of optimizations.
At the other hand it don't see original purpose of code as with define_split.
So for exmaple if you expand DI mode shifts, you can not expect
to get (a<<3)<<4 optimized to a<<7. This is IMO quite complex decision.
>
> > Also, I'm wondering about Jan's patches. None of them seem to have
> > gone into the CVS tree yet. Is there a holdup on the copyright
> > assignment form, or some other problem?
> They were held up on copyright issues. I just checked the FSF copyright list
> and Jan's copyright assignment has been filed. So I guess we need to look at
> his patches more closely now :-) :-)
Cool!
So please let me know what do you think abou those first two parts I've sent.
I will prepare more as soon as this two are discussed (My experience is that
discussion about one part forces me to rewrite other, so it is probably
useless to do more paralelizm..)
I would love to see major parts of my patch in, since it is harder
to maitain such relatively large amout of changes. I am just having
hard time with making egcs with my patch bootstraping again after
weekend. Thinks should be easier with smaller patch..
Honza