This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/15826] don't use "if" to extract a single bit bit-field.


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15826

--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Steven Bosscher from comment #6)
> The tree dump for the original test case now looks like this for me:
> 
> ;; Function foo (foo)
> 
> foo (p)
> {
> <bb 2>:
>   return (unsigned int) ((BIT_FIELD_REF <*p, 8, 0> & 1) != 0);
> 
> }
> 
> 
> 
> ;; Function bar (bar)
> 
> bar (p)
> {
> <bb 2>:
>   return (unsigned int) p->bit;
> 
> }
> 
> 
> 
> The resulting assembler output is the same, but I imagine VRP should be able
> to fold away the "& 1" test.  I don't know if the BIT_FIELD_REF itself
> should be optimized away, but I guess so.  Consider the following test case:
> 
> struct s
> {
>   unsigned int bit:1;
> };
> 
> unsigned int
> foo (struct s *p)
> {
>   if (p->bit)
>     return (unsigned int) (p->bit);
>   else
>     return 0;
> }
> 
> 
> This gets "optimized" at the tree level to this ugly code:
> ;; Function foo (foo)
> 
> foo (p)
> {
>   unsigned int D.1979;
> 
> <bb 2>:
>   if ((BIT_FIELD_REF <*p, 8, 0> & 1) != 0) goto <L0>; else goto <L4>;
> 
> <L4>:;
>   D.1979 = 0;
>   goto <bb 5> (<L2>);
> 
> <L0>:;
>   D.1979 = (unsigned int) p->bit;
> 
> <L2>:;
>   return D.1979;
> 
> }
> 
> In summary, I don't think we can close this bug just yet.

I don't think VRP can optimize anything here as the BIT_FIELD_REF created
by optimize_bitfield_compare accesses struct s tail-padding.

IMHO this is still very premature optimization done by fold.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]