Re: [RFC] PR 58542: const_int vs lost modes

2013-10-24 Thread Richard Henderson
On 10/24/2013 05:02 AM, Richard Sandiford wrote: > Do we actually need to do a conversion here at all? It looks like the > modes of "expected" and "desired" should already match "mem", so we could > just use create_input_operand. This works. I've committed the following to mainline, and will tes

Re: [RFC] PR 58542: const_int vs lost modes

2013-10-24 Thread Richard Sandiford
Eric Botcazou writes: >> That's a fairly dangerous hack in my opinion, in particular this breaks the >> uniqueness of representation of -1 as constm1_rtx. Can't we find a really >> contained hack instead, especially if we want to backport it to 4.8? > > In particular, can't Uros' patch be conside

Re: [RFC] PR 58542: const_int vs lost modes

2013-10-24 Thread Eric Botcazou
> That's a fairly dangerous hack in my opinion, in particular this breaks the > uniqueness of representation of -1 as constm1_rtx. Can't we find a really > contained hack instead, especially if we want to backport it to 4.8? In particular, can't Uros' patch be considered as such here? Frankly, t

Re: [RFC] PR 58542: const_int vs lost modes

2013-10-24 Thread Richard Biener
On Thu, Oct 24, 2013 at 10:43 AM, Eric Botcazou wrote: >> The most isolated patch I can come up with, especially since we ought to >> fix this in 4.8 branch as well, is to only allow expansion of wide int >> modes to const_int when they're positive. >> >> Thoughts? > > That's a fairly dangerous ha

Re: [RFC] PR 58542: const_int vs lost modes

2013-10-24 Thread Eric Botcazou
> The most isolated patch I can come up with, especially since we ought to > fix this in 4.8 branch as well, is to only allow expansion of wide int > modes to const_int when they're positive. > > Thoughts? That's a fairly dangerous hack in my opinion, in particular this breaks the uniqueness of