This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: i370 port
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: mutazilah at gmail dot com (Paul Edwards)
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 25 Sep 2009 17:16:25 +0200 (CEST)
- Subject: Re: i370 port
Paul Edwards wrote:
> As such, it's appropriate to simply comment it out (which was my
> "workaround"). However, before I do so, do you think this is close
> to being correct? I already made one correction, to put in that
> XL1 rather than doing a fullword (which was always zero obviously).
>
>
> (define_insn "movstrictqi"
> [(set (strict_low_part (match_operand:QI 0 "nonimmediate_operand" "+d"))
> (match_operand:QI 1 "general_operand" "g"))]
> ""
> "*
> {
> check_label_emit ();
> if (REG_P (operands[1]))
> {
> mvs_check_page (0, 8, 0);
> return \"STC^I%1,\" CONVLO \"(,13)\;IC^I%0,\" CONVLO \"(,13)\";
> }
> mvs_check_page (0, 4, 0);
> return \"IC^I%0,=XL1'%X1'\";
> }"
> [(set_attr "length" "8")]
> )
The one obvious problem I see with this pattern is that the predicate
and constraint for operand 1 allow register, immediate and *memory*
operands, but the body seems to only handle register and immediate
operands correctly.
The STC followed by IC is of course correct, but will cause significant
penalities on all modern machines. Just about any other way to load
the low byte (e.g. and with mask, then or) would be more efficient ...
> Which I can clearly see is different. Specifically, the IC by itself is
> fine,
> although I would have preferred to see the LA instruction there, but for
> some reason it is dropping the CLR. That makes it technically
> incorrect.
This is odd. I don't quite see why this would happen. You should look
into the RTL dump files generated via -da to see where the compare insn
disappears ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com