This is the mail archive of the gcc@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]

Re: Generated libcalls


> But mostly because I'd rather avoid the inevitable discussion that
> would follow the proposal to add a new #pragma ;->

Indeed, so just ignore that proposal...

> The problem with this matter is, that, as Jan Hubicka pointed out to
> me, it's rather hard to implement such a switch as at that point, a
> libcall is just another function. I've never dealt with gcc on that
> level so I can't make comments about the validity of that statement.

Maybe I'm missing something, but... Currently, determination whether
to use memcpy or not is made with the line

  if (GET_CODE (size) == CONST_INT && MOVE_BY_PIECES_P (INTVAL (size), align))
    move_by_pieces (x, y, INTVAL (size), align);

I can't see the problem changing this to

  if (GET_CODE (size) == CONST_INT 
      && (flag_freestanding || MOVE_BY_PIECES_P (INTVAL (size), align)))
    move_by_pieces (x, y, INTVAL (size), align);

Of course, you'll have to catch a number of other cases as well
(e.g. clear-by-pieces), and you'll have to consider the case that
there's a copy where the size is not constant. However, I guess this
does not come up out of the compiler itself, only perhaps as a result
from calling __builtin_memcpy - which you shouldn't do in a
freestanding environment.

Please let me know if you do follow this approach.

Regards,
Martin

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