On Tue, Oct 12, 2021 at 05:25:32PM -0500, Segher Boessenkool wrote:
> On Tue, Oct 12, 2021 at 02:35:57PM -0500, Paul A. Clarke wrote:
> > static __inline __attribute__ ((__always_inline__)) void
> > libc_feholdsetround_ppc_ctx (struct rm_ctx *ctx, int r)
> > {
> > fenv_union_t old;
> > register
On Tue, Oct 12, 2021 at 02:35:57PM -0500, Paul A. Clarke wrote:
> You asked for it. ;-) Boiled down to remove macroisms and code that
> should be removed by optimization:
Thanks :-)
> static __inline __attribute__ ((__always_inline__)) void
> libc_feholdsetround_ppc_ctx (struct rm_ctx *ctx, int
On Mon, Oct 11, 2021 at 05:04:12PM -0500, Segher Boessenkool wrote:
> On Mon, Oct 11, 2021 at 12:31:07PM -0500, Paul A. Clarke wrote:
> > On Mon, Oct 11, 2021 at 11:28:39AM -0500, Segher Boessenkool wrote:
> > > > Very similar methods are used in glibc today. Are those broken?
> > >
> > > Maybe.
>
Hi!
On Mon, Oct 11, 2021 at 12:31:07PM -0500, Paul A. Clarke wrote:
> On Mon, Oct 11, 2021 at 11:28:39AM -0500, Segher Boessenkool wrote:
> > > Very similar methods are used in glibc today. Are those broken?
> >
> > Maybe.
>
> Ouch.
So show the code?
> > If you get a real (i.e. not inline) fun
On Mon, Oct 11, 2021 at 11:28:39AM -0500, Segher Boessenkool wrote:
> On Mon, Oct 11, 2021 at 08:46:17AM -0500, Paul A. Clarke wrote:
> > On Fri, Oct 08, 2021 at 05:31:11PM -0500, Segher Boessenkool wrote:
[...]
> > > > With respect to volatile, I worry about removing it, because I do
> > > > indee
On Mon, Oct 11, 2021 at 08:46:17AM -0500, Paul A. Clarke wrote:
> On Fri, Oct 08, 2021 at 05:31:11PM -0500, Segher Boessenkool wrote:
> > "asm volatile" means there is a side effect in the asm. This means that
> > it has to be executed on the real machine the same as on the abstract
> > machine, w
On Fri, Oct 08, 2021 at 05:31:11PM -0500, Segher Boessenkool wrote:
> On Fri, Oct 08, 2021 at 02:27:28PM -0500, Paul A. Clarke wrote:
> > On Fri, Oct 08, 2021 at 12:39:15PM -0500, Segher Boessenkool wrote:
> > I see. Thanks for the reference. If I understand correctly, volatile
> > prevents some op
On Fri, Oct 08, 2021 at 02:27:28PM -0500, Paul A. Clarke wrote:
> On Fri, Oct 08, 2021 at 12:39:15PM -0500, Segher Boessenkool wrote:
> > This is not a basic asm (it contains a ":"; that is not just an easy way
> > to see it, it is the *definition* of basic vs. extended asm).
>
> Ah, basic vs exte
On Fri, Oct 08, 2021 at 12:39:15PM -0500, Segher Boessenkool wrote:
> On Thu, Oct 07, 2021 at 08:04:23PM -0500, Paul A. Clarke wrote:
> > On Thu, Oct 07, 2021 at 06:39:06PM -0500, Segher Boessenkool wrote:
> > > > + __asm__ __volatile__ ("mffsce %0" : "=f" (__fpscr_save.__fr));
> > >
> > > Th
On Thu, Oct 07, 2021 at 08:04:23PM -0500, Paul A. Clarke wrote:
> On Thu, Oct 07, 2021 at 06:39:06PM -0500, Segher Boessenkool wrote:
> > > + __asm__ __volatile__ ("mffsce %0" : "=f" (__fpscr_save.__fr));
> >
> > The __volatile__ does likely not do what you want. As far as I can see
> > you
On Thu, Oct 07, 2021 at 06:39:06PM -0500, Segher Boessenkool wrote:
> On Mon, Aug 23, 2021 at 02:03:05PM -0500, Paul A. Clarke wrote:
> > No attempt is made to optimize writing the FPSCR (by checking if the new
> > value would be the same), other than using lighter weight instructions
> > when poss
On Mon, Aug 23, 2021 at 02:03:05PM -0500, Paul A. Clarke wrote:
> No attempt is made to optimize writing the FPSCR (by checking if the new
> value would be the same), other than using lighter weight instructions
> when possible.
__builtin_set_fpscr_rn makes optimised code (using mtfsb[01])
automat
On Mon, Aug 30, 2021 at 04:16:43PM -0500, Paul A. Clarke wrote:
> The confusing thing is that _builtin_mffsl is explicitly supported on earlier
> processors, if I read the code right (from gcc/config/rs6000/rs6000.md):
Yes. It is very simple to implement everywhere, not significantly
slower than
Hi Paul,
On 8/30/21 4:16 PM, Paul A. Clarke wrote:
On Fri, Aug 27, 2021 at 08:44:43AM -0500, Bill Schmidt via Gcc-patches wrote:
On 8/23/21 2:03 PM, Paul A. Clarke wrote:
+ __fpscr_save.__fr = __builtin_mffsl ();
As pointed out in the v1 review, __builtin_mffsl is enabled (or supposed t
On Fri, Aug 27, 2021 at 08:44:43AM -0500, Bill Schmidt via Gcc-patches wrote:
> On 8/23/21 2:03 PM, Paul A. Clarke wrote:
> > + __fpscr_save.__fr = __builtin_mffsl ();
>
> As pointed out in the v1 review, __builtin_mffsl is enabled (or supposed to
> be) only for POWER9 and later. This will fail
On 8/27/21 8:44 AM, Bill Schmidt wrote:
Again, please specify where the patch was tested and whether this is for
trunk, backports, etc. Thanks! (I know you aren't asking for
backports, but in general please get in the habit of this.)
Sorry, I see that you did this in the cover letter. Ne
Hi Paul,
On 8/23/21 2:03 PM, Paul A. Clarke wrote:
Suppress exceptions (when specified), by saving, manipulating, and
restoring the FPSCR. Similarly, save, set, and restore the floating-point
rounding mode when required.
No attempt is made to optimize writing the FPSCR (by checking if the new
Suppress exceptions (when specified), by saving, manipulating, and
restoring the FPSCR. Similarly, save, set, and restore the floating-point
rounding mode when required.
No attempt is made to optimize writing the FPSCR (by checking if the new
value would be the same), other than using lighter wei
18 matches
Mail list logo
