[EMAIL PROTECTED] wrote:
Just to follow up on this email since I looked into some of the
issues a little more last night.
The problem here is the translation table is broken.
Here is what we get on powerpc-darwin:
Class cover:
FLOAT_REGS NON_FLOAT_REGS
Class translation:
NO_REGS -> NO_REGS
BASE_REGS -> NO_REGS
GENERAL_REGS -> NO_REGS
FLOAT_REGS -> FLOAT_REGS
ALTIVEC_REGS -> NO_REGS
VRSAVE_REGS -> NO_REGS
VSCR_REGS -> NO_REGS
SPE_ACC_REGS -> NO_REGS
SPEFSCR_REGS -> NO_REGS
NON_SPECIAL_REGS -> NO_REGS
MQ_REGS -> NON_FLOAT_REGS
LINK_REGS -> NON_FLOAT_REGS
CTR_REGS -> NON_FLOAT_REGS
LINK_OR_CTR_REGS -> NON_FLOAT_REGS
SPECIAL_REGS -> NO_REGS
SPEC_OR_GEN_REGS -> NO_REGS
CR0_REGS -> NON_FLOAT_REGS
CR_REGS -> NON_FLOAT_REGS
NON_FLOAT_REGS -> NON_FLOAT_REGS
XER_REGS -> NO_REGS
ALL_REGS -> NO_REGS
GENERAL_REGS points to NO_REGS which means we always spill :(.
This is the same issue as the thrid problem in fact.
Yes, I know about this. I tried a quick fix several weeks ago but the
fix broke x86. I'll solve the problem when I have time for this.
---------------------------------------------------------------------------
And then I decided just to look into code generation:
int f(void)
{
return 0;
}
---------------------------------------------------------------------------
With the above code, I noticed that GCC saved and restored
the link register which is not needed because this is a leaf function.
The saving and restoring of the link register can be solved by the
attached
patch which should also help x86 code gen at the same time (I have not
bootstrapped
it yet there).
I know about the code too but unfortunately it should wait because it
gives a big degradation of eon for x86. I need to find time to analyze
the reason of the degradation (which is not easy for big benchmarks as eon).
Thanks for your interest in YARA.
Vlad
