Thanks for helping fixing it. I will take care to verify regression
and bootstrap before checkin to release branches next time.
Regards,
Wei.
On Wed, Apr 3, 2013 at 11:08 AM, Jakub Jelinek wrote:
> On Thu, Mar 28, 2013 at 04:49:47PM +0100, Uros Bizjak wrote:
>> 2013-03-27 Wei Mi
>>
>> *
On Thu, Mar 28, 2013 at 04:49:47PM +0100, Uros Bizjak wrote:
> 2013-03-27 Wei Mi
>
> * config/i386/i386.md: Do shift truncation in define_insn
> instead of define_insn_and_split.
>
> Please write ChangeLog as:
>
> * config/i386/i386.md (*ashl3_mask): Rewrite as define_insn.
On Tue, Apr 2, 2013 at 7:43 AM, Wei Mi wrote:
> I attached the patch.4 based on r197308. r197308 changes shift-and
> type truncation from define_insn_and_split to define_insn. patch.4
> changes ix86_rtx_costs for shift-and type rtx to get the correct cost
> for the result after the shift-and trun
1.c attached.
On Mon, Apr 1, 2013 at 10:43 PM, Wei Mi wrote:
> I attached the patch.4 based on r197308. r197308 changes shift-and
> type truncation from define_insn_and_split to define_insn. patch.4
> changes ix86_rtx_costs for shift-and type rtx to get the correct cost
> for the result after th
On Thu, Mar 28, 2013 at 5:34 AM, Wei Mi wrote:
> I am not familiar how to use define_subst, so I write a patch that
> changes define_insn_and_split to define_insn. bootstrapped and
> regression tested on x86_64-unknown-linux-gnu.
>
> A question is: after that change, Is there anyway I can make
> t
I am not familiar how to use define_subst, so I write a patch that
changes define_insn_and_split to define_insn. bootstrapped and
regression tested on x86_64-unknown-linux-gnu.
A question is: after that change, Is there anyway I can make
targetm.rtx_costs() aware about the truncation, .i.e the cos
On Tue, Mar 26, 2013 at 10:14 AM, Richard Biener
wrote:
>>> I am trying to figure out a way not to lose the opportunity when shift
>>> truncation is not combined in a bit test pattern. Can we keep the
>>> explicit truncation in RTL, but generate truncation code in assembly?
>>> Then only shift tru
On Mon, Mar 25, 2013 at 6:33 PM, Wei Mi wrote:
>> I am trying to figure out a way not to lose the opportunity when shift
>> truncation is not combined in a bit test pattern. Can we keep the
>> explicit truncation in RTL, but generate truncation code in assembly?
>> Then only shift truncation which
> I am trying to figure out a way not to lose the opportunity when shift
> truncation is not combined in a bit test pattern. Can we keep the
> explicit truncation in RTL, but generate truncation code in assembly?
> Then only shift truncation which not combined in a bit test
> pattershift truncation
On Mon, Mar 25, 2013 at 2:35 AM, Richard Biener
wrote:
> On Sun, Mar 24, 2013 at 5:18 AM, Wei Mi wrote:
>> This is the patch to add the shift truncation in
>> simplify_binary_operation_1. I add a new hook
>> TARGET_SHIFT_COUNT_TRUNCATED which uses enum rtx_code to decide
>> whether we can do shif
On Sun, Mar 24, 2013 at 5:18 AM, Wei Mi wrote:
> This is the patch to add the shift truncation in
> simplify_binary_operation_1. I add a new hook
> TARGET_SHIFT_COUNT_TRUNCATED which uses enum rtx_code to decide
> whether we can do shift truncation. I didn't use
> TARGET_SHIFT_TRUNCATION_MASK in s
Hi,
On Sat, 2013-03-23 at 21:18 -0700, Wei Mi wrote:
> This is the patch to add the shift truncation in
> simplify_binary_operation_1. I add a new hook
> TARGET_SHIFT_COUNT_TRUNCATED which uses enum rtx_code to decide
> whether we can do shift truncation. I didn't use
> TARGET_SHIFT_TRUNCATION_MAS
This is the patch to add the shift truncation in
simplify_binary_operation_1. I add a new hook
TARGET_SHIFT_COUNT_TRUNCATED which uses enum rtx_code to decide
whether we can do shift truncation. I didn't use
TARGET_SHIFT_TRUNCATION_MASK in simplify_binary_operation_1 because it
uses the macro SHIFT
On Sun, Mar 17, 2013 at 12:15 AM, Wei Mi wrote:
> Hi,
>
> On Sat, Mar 16, 2013 at 3:48 PM, Steven Bosscher
> wrote:
>> On Tue, Mar 12, 2013 at 8:18 AM, Wei Mi wrote:
>>> For the motivational case, I need insn splitting to get the cost
>>> right. insn splitting is not very intrusive. All I need i
On Tue, Mar 12, 2013 at 8:18 AM, Wei Mi wrote:
> For the motivational case, I need insn splitting to get the cost
> right. insn splitting is not very intrusive. All I need is to call
> split_insns func.
It may not look very intrusive, but there's a lot happening in the
back ground. You're creating
Thanks for the helpful comments! I have some replies inlined.
Regards,
Wei.
On Mon, Mar 11, 2013 at 12:52 PM, Steven Bosscher wrote:
> On Mon, Mar 11, 2013 at 6:52 AM, Wei Mi wrote:
>> This is the fwprop extension patch which is put in order. Regression
>> test and bootstrap pass. Please help to
On Mon, Mar 11, 2013 at 6:52 AM, Wei Mi wrote:
> This is the fwprop extension patch which is put in order. Regression
> test and bootstrap pass. Please help to review its rationality. The
> following is a brief description what I have done in the patch.
>
> In order to make fwprop more effective in
On Mon, Mar 11, 2013 at 7:10 PM, Jeff Law wrote:
> On 03/10/2013 11:52 PM, Wei Mi wrote:
>>
>> Hi,
>>
>> This is the fwprop extension patch which is put in order. Regression
>> test and bootstrap pass. Please help to review its rationality. The
>> following is a brief description what I have done
On 03/10/2013 11:52 PM, Wei Mi wrote:
Hi,
This is the fwprop extension patch which is put in order. Regression
test and bootstrap pass. Please help to review its rationality. The
following is a brief description what I have done in the patch.
In order to make fwprop more effective in rtl optimi
Yes, I agree with you. fold_rtx also needs to be extended because now
it only handles the case similar as follows for shift insn:
a = b op const1
c = a >> const2
for our motivational case, the second operand of the first insn is a
reg instead of a const. We also need to add the truncation suppo
On Wed, Feb 27, 2013 at 7:37 PM, Wei Mi wrote:
> What do you think?
I think you'll not be able to teach fold_rtx to perform the
transformation you want it to do without having SHIFT_COUNT_TRUNCATED
set for i386. I already tried it the other day, but GCC won't do the
truncation without knowing the
On Tue, Feb 26, 2013 at 2:59 AM, Steven Bosscher wrote:
> On Tue, Feb 26, 2013 at 2:12 AM, Wei Mi wrote:
>> But it is not a good transformation unless we know insn split will
>> change a << (b & 63) to a << b; Here we want to see what the rtl looks
>> like after insn splitting in fwprop cost estim
On Tue, Feb 26, 2013 at 2:12 AM, Wei Mi wrote:
> But it is not a good transformation unless we know insn split will
> change a << (b & 63) to a << b; Here we want to see what the rtl looks
> like after insn splitting in fwprop cost estimation (We call
> split_insns in estimate_split_and_peephole(),
Hi,
On Mon, Feb 25, 2013 at 4:08 PM, Steven Bosscher wrote:
> On Tue, Feb 26, 2013 at 12:32 AM, Wei Mi wrote:
>> We also take insn splitting and peephole into consideration,
>> .i.e, the cost of the change is the cost after insn splitting and
>> peephole which may be applied to the insn changed.
On Tue, Feb 26, 2013 at 12:32 AM, Wei Mi wrote:
> We also take insn splitting and peephole into consideration,
> .i.e, the cost of the change is the cost after insn splitting and
> peephole which may be applied to the insn changed. This is useful for
> the motivational case,
It also goes against e
25 matches
Mail list logo
