On 23/05/14 07:23, Richard Henderson wrote:
> On 05/22/2014 03:12 AM, Jakub Jelinek wrote:
>> No way. SUBREG_PROMOTED_UNSIGNED_P right now resides in two separate bits,
>> volatil and unchanging. Right now volatile != 0, unchanging ignored
>> is -1, volatile == 0, then the value is unchanging.
>>
On 05/22/2014 03:12 AM, Jakub Jelinek wrote:
> No way. SUBREG_PROMOTED_UNSIGNED_P right now resides in two separate bits,
> volatil and unchanging. Right now volatile != 0, unchanging ignored
> is -1, volatile == 0, then the value is unchanging.
> What I meant is change this representation, e.g.
On Thu, May 22, 2014 at 08:01:45PM +1000, Kugan wrote:
> --- a/gcc/expr.c
> +++ b/gcc/expr.c
> @@ -328,7 +328,8 @@ convert_move (rtx to, rtx from, int unsignedp)
>if (GET_CODE (from) == SUBREG && SUBREG_PROMOTED_VAR_P (from)
>&& (GET_MODE_PRECISION (GET_MODE (SUBREG_REG (from)))
>
On 21/05/14 17:05, Jakub Jelinek wrote:
> On Wed, May 21, 2014 at 12:53:47PM +1000, Kugan wrote:
>> On 20/05/14 16:52, Jakub Jelinek wrote:
>>> On Tue, May 20, 2014 at 12:27:31PM +1000, Kugan wrote:
1. Handling NOP_EXPR or CONVERT_EXPR that are in the IL because they
are required for typ
On Wed, May 21, 2014 at 12:53:47PM +1000, Kugan wrote:
> On 20/05/14 16:52, Jakub Jelinek wrote:
> > On Tue, May 20, 2014 at 12:27:31PM +1000, Kugan wrote:
> >> 1. Handling NOP_EXPR or CONVERT_EXPR that are in the IL because they
> >> are required for type correctness. We have two cases here:
> >>
On 20/05/14 16:52, Jakub Jelinek wrote:
> On Tue, May 20, 2014 at 12:27:31PM +1000, Kugan wrote:
>> 1. Handling NOP_EXPR or CONVERT_EXPR that are in the IL because they
>> are required for type correctness. We have two cases here:
>>
>> A) Mode is smaller than word_mode. This is usually from wher
On Tue, May 20, 2014 at 12:27:31PM +1000, Kugan wrote:
> 1. Handling NOP_EXPR or CONVERT_EXPR that are in the IL because they
> are required for type correctness. We have two cases here:
>
> A) Mode is smaller than word_mode. This is usually from where the
> zero/sign extensions are showing up in
This is based on my earlier patch
https://gcc.gnu.org/ml/gcc-patches/2013-10/msg00452.html. Before I post
the new set of patches, I would like to make sure that I understood
review comments and my idea makes sense and acceptable. Please let me
know If I am missing anything or my assumptions are wr
