This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
(define_mode_const), a proposal
- From: Uros Bizjak <ubizjak at gmail dot com>
- To: GCC Development <gcc at gcc dot gnu dot org>
- Date: Fri, 9 Jul 2010 15:00:48 +0200
- Subject: (define_mode_const), a proposal
Hello!
During the macroization of x86 RTX patterns, it became clear that
certain patterns can't be macroized due to mode-dependant (const_int
N) RTXes, where the value of X depends on current mode. As an example,
here are two insn patterns from i386/i386.md:
(define_insn "x86_64_shld"
[(set (match_operand:DI 0 "nonimmediate_operand" "+r*m")
(ior:DI (ashift:DI (match_dup 0)
(match_operand:QI 2 "nonmemory_operand" "Jc"))
(lshiftrt:DI (match_operand:DI 1 "register_operand" "r")
(minus:QI (const_int 64) (match_dup 2)))))
(clobber (reg:CC FLAGS_REG))]
...
and
(define_insn "x86_shld"
[(set (match_operand:SI 0 "nonimmediate_operand" "+r*m")
(ior:SI (ashift:SI (match_dup 0)
(match_operand:QI 2 "nonmemory_operand" "Ic"))
(lshiftrt:SI (match_operand:SI 1 "register_operand" "r")
(minus:QI (const_int 32) (match_dup 2)))))
(clobber (reg:CC FLAGS_REG))]
""
...
These two patterns could easily be macroized, however - there is no
way to express (const_int N) mode dependency*.
If we have had a define_mode_constant expression, similar to
define_mode_attr, where:
(define_mode_const WSZ [(SI "32") (DI "64")])
we could macroize the pattern to:
(define_insn "shld_<mode>"
[(set (match_operand:SWI48 0 "nonimmediate_operand" "+r*m")
(ior:SWI48 (ashift:SWI48 (match_dup 0)
(match_operand:QI 2 "nonmemory_operand" "<S>c"))
(lshiftrt:SWI48 (match_operand:SWI48 1 "register_operand" "r")
(minus:QI (const_int {WSZ}) (match_dup 2)))))
(clobber (reg:CC FLAGS_REG))]
""
...
where {WSZ} would get expanded to correct number through WSZ define_mode_const.
This would help to macroize various push instructions throughout
i386.md and (more important) numerous string instructions, in addition
to the patterns, similar to the example above.
I'm posting this in hope that somebody would pick this idea, my skills
are too limited to implement this proposal by myself ...
* In expanders, it is possible to play various games with (match_dup
...) and create correct integer operand in insn prepare statements.
However, it would be more readable if we could embed correct integer
in the pattern itself.
Uros.