FYI, I'm putting in this follow-up tweak to the GNAT manual.
Implied compares in Ada Harded Conditionals documentation
From: Alexandre Oliva
Improve the wording on optimizations that prevent compare hardening,
so as to also cover cases in which explicit compares get combined into
operations wi
On Oct 26, 2021, Richard Biener wrote:
> OK.
Thanks. I've just fixed the ChangeLog entry and pushed it:
>> * common.opt (fharden-compares): New.
>> (fharden-conditional-branches): New.
>> * doc/invoke.texi: Document new options.
>> * gimple-harden-conditionals.cc: New.
+ * Makefile.in (OBJS)
On Fri, Oct 22, 2021 at 4:19 AM Alexandre Oliva wrote:
>
> On Oct 20, 2021, Alexandre Oliva wrote:
>
> > I suppose it's a latent issue exposed by the patch,
>
> I was mistaken. Though I even had bisected the -fcompare-debug problem
> back to a patch from back in May, that added a new sink_code p
On Oct 20, 2021, Alexandre Oliva wrote:
> I suppose it's a latent issue exposed by the patch,
I was mistaken. Though I even had bisected the -fcompare-debug problem
back to a patch from back in May, that added a new sink_code pass before
store_merging, it was actually a bug in my patch, it was
On Oct 18, 2021, Richard Biener wrote:
> Yes, it is (just having had a quick look most of the functions in the
> pass lack function-level comments).
Oh my, I'm so sorry, please accept my apologies. I stepped away from
this patch for a few weeks, and when I got back to it, I did not realize
it w
On Fri, Oct 15, 2021 at 8:35 PM Alexandre Oliva wrote:
>
> On Oct 14, 2021, Richard Biener wrote:
>
> > Yeah, I think that eventually marking the operation we want to preserve
> > (with volatile?) would be the best way. On GIMPLE that's difficult,
> > it's easier on GENERIC (we can set TREE_THIS
On Oct 14, 2021, Richard Biener wrote:
> Yeah, I think that eventually marking the operation we want to preserve
> (with volatile?) would be the best way. On GIMPLE that's difficult,
> it's easier on GENERIC (we can set TREE_THIS_VOLATILE on the
> expression at least), and possibly also on RTL (
On Wed, Oct 13, 2021 at 8:54 PM Alexandre Oliva wrote:
>
> On Oct 12, 2021, Richard Biener wrote:
>
> > Are there any issues with respect to debugging when using such
> > asm()s?
>
> Not in this case. When creating short-lived copies for immediate use,
> like I do in the proposed patch, either t
On Oct 12, 2021, Richard Biener wrote:
> Are there any issues with respect to debugging when using such
> asm()s?
Not in this case. When creating short-lived copies for immediate use,
like I do in the proposed patch, either the original value remains live
in its original location and we use an
On Tue, Oct 12, 2021 at 8:35 AM Alexandre Oliva wrote:
>
> On Oct 9, 2021, Richard Biener wrote:
>
> > Why two passes (and two IL traverses?)
>
> Different traversals, no reason to force them into a single pass. One
> only looks at the last stmt of each block, where cond stmts may be,
> while t
On Oct 9, 2021, Richard Biener wrote:
> Why two passes (and two IL traverses?)
Different traversals, no reason to force them into a single pass. One
only looks at the last stmt of each block, where cond stmts may be,
while the other has to look at every stmt.
> How do you prevent RTL optimiz
On October 9, 2021 5:30:04 AM GMT+02:00, Alexandre Oliva via Gcc-patches
wrote:
>
>This patch introduces optional passes to harden conditionals used in
>branches, and in computing boolean expressions, by adding redundant
>tests of the reversed conditions, and trapping in case of unexpected
>resul
This patch introduces optional passes to harden conditionals used in
branches, and in computing boolean expressions, by adding redundant
tests of the reversed conditions, and trapping in case of unexpected
results. Though in abstract machines the redundant tests should never
fail, CPUs may be le
13 matches
Mail list logo
