On Thu, 2015-11-05 at 15:33 -0500, David Miller wrote: > From: David Miller <davem@xxxxxxxxxxxxx> > Date: Wed, 28 Oct 2015 18:44:15 -0700 (PDT) > > > From: David Woodhouse <dwmw2@xxxxxxxxxxxxx> > > Date: Wed, 28 Oct 2015 23:53:52 +0900 > > > >> I know MIPS will need some additional libgcc functionality brought > >> into the kernel, and Ralf has already been looking at that; not sure > >> about other platforms. Let's find out :) > > > > It should properly build on Sparc, but I still need to do my due > > diligence to see if gcc will actually emit the little-endian loads > > and stores or not... > > It does not, instead it emits libgcc calls. > > So I don't I can use this on sparc. .... > > I wonder if we could provide a generic weak version in the lib/ > > directory which just uses the existing __arch_swab32 et al? Does GCC > > use a standard function call ABI for __bswap[sd]i2 or can it be > > 'special'? > > That's undesirable compared to inlining the asm. So... GCC knows *exactly* what this builtin function does. It is better to inline it than to call an out-of-line function. Yet GCC emits an out-of-line call instead of just inlining it. Is that not something we should be filing a GCC PR for? Basically, we are working around a GCC misbehaviour by using opaque inline asm instead of the GCC builtins that *currently* happen to result in suboptimal code. We've mostly learned our lesson *not* to do that kind of thing :) -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
