On 19/11/14 09:29, Yangfei (Felix) wrote:
Sorry for missing the point. It seems to me that 't2' here will conflict with
condition of the pattern *movhi_insn_arch4:
TARGET_ARM
arm_arch4
(register_operand (operands[0], HImode)
|| register_operand (operands[1],
On 19/11/14 09:29, Yangfei (Felix) wrote:
Sorry for missing the point. It seems to me that 't2' here will
conflict with
condition of the pattern *movhi_insn_arch4:
TARGET_ARM
arm_arch4
(register_operand (operands[0], HImode)
|| register_operand
On 19/11/14 09:29, Yangfei (Felix) wrote:
Sorry for missing the point. It seems to me that 't2' here will
conflict with
condition of the pattern *movhi_insn_arch4:
TARGET_ARM
arm_arch4
(register_operand (operands[0], HImode)
|| register_operand
Sorry for missing the point. It seems to me that 't2' here will conflict
with
condition of the pattern *movhi_insn_arch4:
TARGET_ARM
arm_arch4
(register_operand (operands[0], HImode)
|| register_operand (operands[1], HImode))
#define TARGET_ARM
On 19/11/14 09:29, Yangfei (Felix) wrote:
Sorry for missing the point. It seems to me that 't2' here will conflict with
condition of the pattern *movhi_insn_arch4:
TARGET_ARM
arm_arch4
(register_operand (operands[0], HImode)
|| register_operand (operands[1],
On 06/11/14 08:35, Yangfei (Felix) wrote:
The idea is simple: Use movw for certain const source operand instead of
ldrh. And exclude the const values which cannot be handled by
mov/mvn/movw.
I am doing regression test for this patch. Assuming no issue pops up,
OK for trunk?
On 06/11/14 08:35, Yangfei (Felix) wrote:
The idea is simple: Use movw for certain const source operand
instead of
ldrh. And exclude the const values which cannot be handled by
mov/mvn/movw.
I am doing regression test for this patch. Assuming no issue
pops up,
OK for
On 18/11/14 11:02, Yangfei (Felix) wrote:
On 06/11/14 08:35, Yangfei (Felix) wrote:
The idea is simple: Use movw for certain const source operand
instead of
ldrh. And exclude the const values which cannot be handled by
mov/mvn/movw.
I am doing regression test for this patch.
On 18/11/14 11:02, Yangfei (Felix) wrote:
On 06/11/14 08:35, Yangfei (Felix) wrote:
The idea is simple: Use movw for certain const source
operand instead of
ldrh. And exclude the const values which cannot be handled by
mov/mvn/movw.
I am doing regression test for this
Sorry for missing the point. It seems to me that 't2' here will conflict with
condition of the pattern *movhi_insn_arch4:
TARGET_ARM
arm_arch4
(register_operand (operands[0], HImode)
|| register_operand (operands[1], HImode))
#define TARGET_ARM (!
Hello,
Any comments on this patch? Thanks.
The idea is simple: Use movw for certain const source operand
instead of
ldrh. And exclude the const values which cannot be handled by
mov/mvn/movw.
I am doing regression test for this patch. Assuming no issue
pops
The idea is simple: Use movw for certain const source operand instead
of
ldrh. And exclude the const values which cannot be handled by
mov/mvn/movw.
I am doing regression test for this patch. Assuming no issue pops up,
OK for trunk?
So, doesn't that makes the bug latent
On 05/11/14 07:09, Yangfei (Felix) wrote:
Hi,
This patch fixes PR63742 by improving arm *movhi_insn_arch4 pattern to
make it works under big-endian.
The idea is simple: Use movw for certain const source operand instead of
ldrh. And exclude the const values which cannot be handled
Hi,
This patch fixes PR63742 by improving arm *movhi_insn_arch4 pattern to make
it works under big-endian.
The idea is simple: Use movw for certain const source operand instead of
ldrh. And exclude the const values which cannot be handled by mov/mvn/movw.
I am doing regression
14 matches
Mail list logo
