Avoiding paradoxical subregs

2014-01-17 Thread Paulo Matos
Hello,

I am seeing GCC combining:
(insn 17 16 18 3 (set (reg:SI 104 [ D.4588 ])
(zero_extend:SI (reg:HI 103 [ D.4587 ]))) test-18.c:24 1426 
{zero_extendhisi2}
 (expr_list:REG_DEAD (reg:HI 103 [ D.4587 ])
(nil)))
(insn 18 17 19 3 (set (reg:BI 105)
(gt:BI (reg:SI 104 [ D.4588 ])
(const_int 4 [0x4]))) test-18.c:24 1372 {cmp_simode}
 (expr_list:REG_DEAD (reg:SI 104 [ D.4588 ])
(nil)))

into a paradoxical use:
(set (reg:BI 105)
(gt:BI (subreg:SI (reg:HI 103 [ D.4587 ]) 0)
(const_int 4 [0x4])))


Reload then transforms (subreg:SI (reg:HI 103 [ D.4587 ]) 0) into (reg:SI 18), 
allocating 103 to 18, but changing the mode to SI.
This is wrong and it will generate wrong code.

I can use canonicalize_comparison like s390 to remove the subreg, however the 
question then becomes about how to avoid this in general. We cannot allow a 
zero_extend to become a paradoxical subreg and then have the subreg discarded. 
Most of our instructions are vector instructions which will change the 
remainder of the register.

I have defined WORD_REGISTER_OPERATIONS and CANNOT_CHANGE_MODE_CLASS(from, to, 
class) and set it to true if GET_MODE_SIZE (from) < GET_MODE_SIZE (to) but it 
didn't help.

Any suggestions for a generic solution?

Paulo Matos




Re: Avoiding paradoxical subregs

2014-01-17 Thread Eric Botcazou
> I can use canonicalize_comparison like s390 to remove the subreg, however
> the question then becomes about how to avoid this in general. We cannot
> allow a zero_extend to become a paradoxical subreg and then have the subreg
> discarded. Most of our instructions are vector instructions which will
> change the remainder of the register.
>
> I have defined WORD_REGISTER_OPERATIONS and CANNOT_CHANGE_MODE_CLASS(from,
> to, class) and set it to true if GET_MODE_SIZE (from) < GET_MODE_SIZE (to)
> but it didn't help.
>
> Any suggestions for a generic solution?

What kind of generic solution?  Eliminating paradoxical subregs altogether?  
That's very likely not doable if you define WORD_REGISTER_OPERATIONS anyway.
You need to pinpoint where things start to go wrong, for example in combine.

-- 
Eric Botcazou


RE: Avoiding paradoxical subregs

2014-01-17 Thread Paulo Matos
> -Original Message-
> From: Eric Botcazou [mailto:ebotca...@adacore.com]
> Sent: 17 January 2014 16:23
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Avoiding paradoxical subregs
> 
> > I can use canonicalize_comparison like s390 to remove the subreg, however
> > the question then becomes about how to avoid this in general. We cannot
> > allow a zero_extend to become a paradoxical subreg and then have the subreg
> > discarded. Most of our instructions are vector instructions which will
> > change the remainder of the register.
> >
> > I have defined WORD_REGISTER_OPERATIONS and CANNOT_CHANGE_MODE_CLASS(from,
> > to, class) and set it to true if GET_MODE_SIZE (from) < GET_MODE_SIZE (to)
> > but it didn't help.
> >
> > Any suggestions for a generic solution?
> 
> What kind of generic solution?  Eliminating paradoxical subregs altogether?
> That's very likely not doable if you define WORD_REGISTER_OPERATIONS anyway.
> You need to pinpoint where things start to go wrong, for example in combine.
> 

I am not implying that this is a GCC bug, unless you think 
WORD_REGISTER_OPERATIONS should have avoided the creation of such paradoxical 
subreg. What I was looking after was for a generic solution on my backend that 
either eliminates the use of paradoxical subregs or forces reload the transform 
(subreg:m (reg:n K)), where subreg is paradoxical, into a zero_extend.

I mentioned a generic one because the only solution I have is for comparison 
instructions only:
canonicalize_comparison (int *, rtx *op0, rtx *,
  bool op0_preserve_value)
{
  if (op0_preserve_value)
return;

  /* Remove paradoxical subregs.  */
  if (GET_CODE (*op0) == SUBREG)
{
  rtx inner = SUBREG_REG (*op0);

  if (GET_MODE_SIZE (GET_MODE (inner)) < GET_MODE_SIZE (GET_MODE (*op0)))
*op0 = simplify_gen_unary (ZERO_EXTEND, GET_MODE (*op0), inner, 
GET_MODE (inner));
}
}

Another more generic solution would be to write my own register_operand 
predicate that excludes paradoxical subregs but I am not sure what kind of 
pandora's box I am opening by doing that.
-- 
Paulo Matos


Re: Avoiding paradoxical subregs

2014-01-17 Thread Eric Botcazou
> I am not implying that this is a GCC bug, unless you think
> WORD_REGISTER_OPERATIONS should have avoided the creation of such
> paradoxical subreg.

No, that's precisely the contrary, WORD_REGISTER_OPERATIONS tends to create 
paradoxical subregs.

> What I was looking after was for a generic solution on
> my backend that either eliminates the use of paradoxical subregs or forces
> reload the transform (subreg:m (reg:n K)), where subreg is paradoxical,
> into a zero_extend.

Why would it do that?  That would pessimize for no clear benefit.  Either the 
paradoxical subreg is correct and there is bug in reload or it is wrong and 
there is a bug in combine.

-- 
Eric Botcazou


V International Workshop on Free and Open Source Software Technologies

2014-01-17 Thread Abel GarcĂ­a Vitier
V International Workshop on Free and Open Source Software Technologies

UCIENCIA 2014

International Scientific Conference of the University of Information Sciences

First Call

Havana, April 2014

The Scientific Council of the University of Informatics Sciences convenes to 
participate in the "V International Workshop on Free and Open Source Software", 
to be held from 24 to 26 April 2014, in Havana, Cuba.

This workshop is dedicated to the use and promotion of open source technologies 
as the most viable alternative to proprietary software in technological 
sovereignty code.

Cuba, like other countries, is betting on the computerization of society from 
the use of free software in an effort to socialize and expand the use of these 
technologies.

The event aims to bring together a group of leading personalities in this field 
in the area to contribute with their ideas and experiences, to promote free 
software not only in Cuba but throughout the continent.

Specific topics
1. Innovative experiences in the adoption of free software and open source.
2. Development and customization of Free Operating Systems.
3. Technical and methodological guides for Free Software migration.
4. Application development on open source.
5. Viability of Open Source for Computer Security at the scene of the Cyberwar.
6. Free Software in academic, working and government environments.
7. Legal and economic aspects of Free Software and Open Source.
8. Business models based on Free Software.

Languages: Spanish - English

Important dates:

February 22, 2014: Deadline for papers receipt.
March 14, 2014: Acceptance by the Scientific Committee.
24-26 April 2014: Development of the event.

Registration Fees:

National Delegates: $ 200.00 CUP
Foreign Delegates: $ 200.00 CUC (1 CUC = 1 USD)

Links:

http://www.uci.cu/?q=uciencia-2014
http://uciencia.uci.cu/
http://humanos.uci.cu/2013/12/convocatoria-al-v-taller-internacional-de-tecnologias-de-software-libre-y-codigo-abierto/

Contact information:

Phone: +537-8372526, +5378372527
E-mail: softwareli...@uci.cu

III Escuela Internacional de Invierno en la UCI del 17 al 28 de febrero del 
2014. Ver www.uci.cu