Re: How to clean up i386 machine description? (plan)

[Jan Hubicka <hubicka at atrey dot karlin dot mff dot cuni dot cz>]

Hi
There seems to be plenty of thinks that we want to change in i386 machine description.
I what thinking what to do next and I fugured out, that it is really
not easy decision. I think it should be usefull to sumarize thinks
here because there is at least two of us, who want to do something
with i386.md. It should help us to choose non conflicting thinks.

Patches I've already sent to list:
1) fix for -mno-ieee-fp bug
2) splits for DI, SF , DF and XF mode moves and pushes
3) small cleanup of predicates

There are also multiple MMX patches waiting....

My current queue of patches contains following quite independent changes:

1) splits for divmod 
2) new insn attributes (this part is significant, but it is not finished
   and it will probably never be. It is still better than current attributes,
   so I think I should send it to egcs-patches soon so others should help me
   to improve it. Rest of my plans in fact targets to improve these attributes)
   I have many new categories in type attribute, the prefix attrubute, improved
   memory attribute, opcode saying wich operands are used, imm_disp saying whether
   instruction has both immediate and displacement and few other new attributes.
3) better detection of AGI stalls and adjust_cost
4) new scheduler definitions for Pentium
5) MD_SCHED macros to implement pairing
6) modified scheduler definitions for K6 and PPro
7) MD_SCHED macros to maximize decoder bandwidth
8) patch for XF move patterns to use constants in SF or DF mode
   if possible. This reduces code size and lets combine to use constant
   operands of arithmetic instructions (i387 can read SF and DF values from
   memory, but not the XF values in instructions other than fld)
9) Better instruction selection for various CPU's (don't use c?l? insns on K6,
   don't use mov $0, reg, since it hurts even on K6,
   on pentium use xor instead of neg and some other similar changes,
   use simple leas even for HI and QI mode arithmetic, use lea for multiply by two,
   don't use mixed FP and integer arithmetic insns on Pentium, bswap patterns,
   shld pattern, splits for shift patterns and some other changes)
10) patch to avoid (const_double (mem...)...) operands for i387 instructions before
   reload, since it prevents CSE from using them as operands of arithmetic instructions
   (because nonimmediate_operand predicate is used)
   (in ChangleLog I see: (LEGITIMATE_CONSTANT_P): Reject CONST_DOUBLEs that are not standard 387 constants.
    isn't it the same?)


We have disussed about following possible changes:

1) change i386.md to not use HAVE_CC0. This will let scheduler do better job, we can improve
   reg_stack to put insns between condition and jump, unhide FP status word and improve/cleanup
   choice of prefixes in HI mode arithmetic
2) rewrite insn patterns to choose instruction according to insn attributes to let scheduler
   know exactly what instruction is used.
3) split patterns whenever possible
4) write better predicates
5) rewrite reg-stack and FP->Integer conversions using LCM
6) rewrite i386.md to use multiple asm dialect support as some other port (I don't remember exactly wich one)
   uses. This seems to be quite simple. You just write {AT&T version | Intel/NASM version} in patterns.
   It should clean up sources and make possible to use @ patterns. Maybe dialec should be selected at runtime. Don't know.
7) riscify optimization using constraints
8) handle FP conversions better using predicates accepting (float_extend (.... (reg/mem)) chains
9) let gcc know about both halves of register. Maybe generic code should handle this using subreg. Don't know

After that we should have nice and clean i386 machine descirption :) Hope I didn't missed
anything significant.

2, 4 and 6 are the easiest IMO. 6 is IMO work for one night. I can do it, but it should introduce large patch,
so we should wait until thinks are settled down. it should make all the pending patches rejecting.

I've already started work at 8, but I've run into problem I've discussed in other mail.

1 2 and 3/4 are most significant IMO. I would like to start with 1, because I think others depends (at least partially)
on it, but I am not sure what needs to be done.
IMO it is:
1) remove HAVE_CC0 :)
2) add constraint letter for both status registers
3) rewrite prefix handling (using REG_DEAD/UNUSED note at condition register)
4) rewrite condition/jump insns
5) rewrite most insns into parallel's that sets cc0 too (and write correct expressions for them).
   I am not sure how to do this part. It will probably look like that (IMO)
   define_insn ""
   [(set (match_operand 0...) ((operator (match_operand 1...) (match_operand 2...))
    (set (condition flags) ((operator (match_dup 1) (match_dup 2))]
   possibly...
   but I am not sure what to do in cases, insn sometimes clobbers flags and sometimes not
   (like add pattern sometimes using lea or mov pattern sometimes using xor)

   Also Bernd says, that some parts of gcc expect that simple arithmetic operations are just
   simple insns not parallels and that it is problem with

Can you please point me to some md file for architecture with similar behaviour and that don't use
HAVE_CC0?

Honza