> On Thu, Aug 24, 2023 at 3:15 PM Jan Hubicka via Gcc-patches
> wrote:
> >
> > Hi,
> > this patch extends verifier to check that all probabilities and counts are
> > initialized if profile is supposed to be present. This is a bit complicated
> &
Hi,
this patch extends verifier to check that all probabilities and counts are
initialized if profile is supposed to be present. This is a bit complicated
by the posibility that we inline !flag_guess_branch_probability function
into function with profile defined and in this case we need to stop
Hi,
this patch adds missing profile update to maybe_optimize_range_tests.
Jakub, I hope I got the code right: I think it basically analyzes the
chain of conditionals, finds some basic blocks involved in the range
testing and then puts all the test into first BB.
The patch fixes
> We seem to peel one iteration for no good reason. The loop is
> a do-while loop already. The key is we see the first iteration
> exit condition is known not taken and then:
Hi,
this is patch fixing wrong return value in should_duplicate_loop_header_p.
Doing so uncovered suboptimal decisions on
>
> We seem to peel one iteration for no good reason. The loop is
> a do-while loop already. The key is we see the first iteration
> exit condition is known not taken and then:
>
> Registering value_relation (path_oracle) (iter.24_6 > iter.24_5) (root:
> bb2)
> Stmt is static (constant
> The following testcase shows that we are bad at identifying inductions
> that will be optimized away after vectorizing them because SCEV doesn't
> handle vectorized defs. The following rolls a simpler identification
> of SSA cycles covering a PHI and an assignment with a binary operator
> with
Hi,
My patch to fix profile after folding internal call is missing check for the
case profile was already zero before if-conversion.
Bootstrapped/regtested x86_64-linux, comitted.
gcc/ChangeLog:
PR gcov-profile/110988
* tree-cfg.cc (fold_loop_internal_call): Avoid division by
Hi,
Profile update I added to tree-ssa-loop-split can divide by zero in
situation that the conditional is predicted with 0 probability which
is triggered by jump threading update in the testcase.
gcc/ChangeLog:
PR middle-end/110923
* tree-ssa-loop-split.cc (split_loop): Watch for
Hi,
this patch makes duplicate_loop_body_to_header_edge to not drop profile counts
to
uninitialized when count_in is 0. This happens because profile_probability in
0 count
is undefined.
Bootstrapped/regtested x86_64-linux, committed.
gcc/ChangeLog:
* cfgloopmanip.cc
Hi,
ssa_fix_duplicate_block_edges later calls update_profile to correct profile
after threading.
In the testcase this does not work since we lose track of the duplicated edge.
This
happens because redirect_edge_and_branch returns NULL if the edge already has
correct
destination which is the
Hi,
This patch avoid overflow in profile_count::differs_from_p and also makes it to
return false from one of the values is undefined while other is defined.
Bootstrapped/regtested x86_64-linux, comitted.
gcc/ChangeLog:
* profile-count.cc (profile_count::differs_from_p): Fix overflow and
> On Thu, Aug 10, 2023 at 9:42 AM Uros Bizjak wrote:
> >
> > On Thu, Aug 10, 2023 at 9:40 AM Richard Biener
> > wrote:
> > >
> > > On Thu, Aug 10, 2023 at 3:13 AM liuhongt wrote:
> > > >
> > > > Currently we have 3 different independent tunes for gather
> > > >
Hi,
If loop is ifconverted and later versioning by vectorizer, vectorizer will
reuse the scalar loop produced by ifconvert. Curiously enough it does not seem
to do so for versions produced by loop distribution while for loop distribution
this matters (since since both ldist versions survive to
Hi,
Epilogue peeling expects the scalar loop to have same number of executions as
the vector loop which is true at the beggining of vectorization. However if the
epilogues are vectorized, this is no longer the case. In this situation the
loop preheader is replaced by new guard code with correct
> On Fri, Aug 4, 2023 at 9:16 AM Jan Hubicka via Gcc-patches
> wrote:
> >
> > Hi,
> > this prevents useless loop distribiton produced in hmmer. With FDO we now
> > correctly work out that the loop created for last iteraiton is not going to
> > iterate howe
Hi,
so I found the problem. We duplicate multiple paths and end up with:
;; basic block 6, loop depth 0, count 365072224 (estimated locally, freq 0.3400)
;; prev block 12, next block 7, flags: (NEW, REACHABLE, VISITED)
;; pred: 4 [never (guessed)] count:0 (estimated locally, freq
Hi,
this prevents useless loop distribiton produced in hmmer. With FDO we now
correctly work out that the loop created for last iteraiton is not going to
iterate however loop distribution still produces a verioned loop that has no
chance to survive loop vectorizer since we only keep distributed
> >
> > A couple cycles ago I separated most of code to distinguish between the
> > back and forward threaders. There is class jt_path_registry that is
> > common to both, and {fwd,back}_jt_path_registry for the forward and
> > backward threaders respectively. It's not perfect, but it's a start.
Hi,
Hmmer's internal function has 4 loops. The following is the profile at start:
loop 1:
estimate 472
iterations by profile: 473.497707 (reliable) count in:84821 (precise, freq
0.9979)
loop 2:
estimate 99
iterations by profile: 100.00 (reliable) count in:39848881
Hi,
Profiledbootstrap fails with ICE in update_loop_exit_probability_scale_dom_bbs
called from loop unroling.
The reason is that under relatively rare situations, we may run into case where
loop has multiple exits and all are considered as likely but then we scale down
the profile and one of the
> > Jeff, an help would be appreciated here :)
> >
> > I will try to debug this. One option would be to disable branch
> > prediciton on vect_check for time being - it is not inlined anyway
> Not a lot of insight. The backwards threader uses a totally different API
> for the CFG/SSA updates and
> On Mon, Jul 31, 2023 at 7:05 PM Martin Jambor wrote:
> >
> > Hi,
> >
> > when IPA-SRA detects whether a parameter passed by reference is
> > written to, it does not special case CLOBBERs which means it often
> > bails out unnecessarily, especially when dealing with C++ destructors.
> > Fixed by
> >
> > Note most of the profile consistency checks FAIL when testing with -m32 on
> > x86_64-unknown-linux-gnu ...
> >
> > For example vect-11.c has
> >
> > ;; basic block 4, loop depth 0, count 719407024 (estimated locally,
> > freq 0.6700), maybe hot
> > ;; Invalid sum of incoming counts
>
> Note most of the profile consistency checks FAIL when testing with -m32 on
> x86_64-unknown-linux-gnu ...
>
> For example vect-11.c has
>
> ;; basic block 4, loop depth 0, count 719407024 (estimated locally,
> freq 0.6700), maybe hot
> ;; Invalid sum of incoming counts 708669602
> The following swaps the loop splitting pass and the final value
> replacement pass to avoid keeping the IV of the earlier loop
> live when not necessary. The existing gcc.target/i386/pr87007-5.c
> testcase shows that we otherwise fail to elide an empty loop
> later. I don't see any good reason
Hi,
Loop distribution and ifcvt introduces verisons of loops which may be removed
later if vectorization fails. Ifcvt does this by temporarily breaking profile
and producing conditional that has two arms with 100% probability because we
know one of the versions will be removed.
Loop distribution
Hi,
This patch fixes update after constant peeling in profilogue. We now reached 0
profile
update bugs on tramp3d vectorizaiton and also on quite few testcases, so I am
enabling the
testuiste checks so we do not regress again.
Bootstrapped/regtested x86_64, comitted.
Honza
gcc/ChangeLog:
Hi,
Vectorizer while loop versioning produces a versioned loop
guarded with two conditionals of the form
if (cond1)
goto scalar_loop
else
goto next_bb
next_bb:
if (cond2)
godo scalar_loop
else
goto vector_loop
It wants the combined test to be prob (whch is set to likely)
> On Fri, Jul 28, 2023 at 2:57 PM Jan Hubicka via Gcc-patches
> wrote:
> >
> > Hi,
> > This patch extends tree-ssa-loop-split to understand test of the form
> > if (i==0)
> > and
> > if (i!=0)
> > which triggers only during the first iteration.
Hi,
This patch extends tree-ssa-loop-split to understand test of the form
if (i==0)
and
if (i!=0)
which triggers only during the first iteration. Naturally we should
also be able to trigger last iteration or split into 3 cases if
the test indeed can fire in the middle of the loop.
Last
> On Fri, Jul 28, 2023 at 9:58 AM Jan Hubicka via Gcc-patches
> wrote:
> >
> > Hi,
> > this patch fixes profile update in the first case of loop splitting.
> > The pass still gives up on very basic testcases:
> >
> > __attribute__ ((noinline,noipa))
>
Hi,
this patch fixes profile update in the first case of loop splitting.
The pass still gives up on very basic testcases:
__attribute__ ((noinline,noipa))
void test1 (int n)
{
if (n <= 0 || n > 10)
return;
for (int i = 0; i <= n; i++)
{
if (i < n)
do_something ();
Hi,
while looking on profile misupdate on hmmer I noticed that loop splitting pass
is not
able to handle the loop it has as an example it should apply on:
One transformation of loops like:
for (i = 0; i < 100; i++)
{
if (i < 50)
A;
else
B;
}
Hi,
as discussed with Richard, we want store to be likely in
optimize_mask_stores.
Bootstrapped/regtested x86_64-linux, comitted.
gcc/ChangeLog:
* tree-vect-loop.cc (optimize_mask_stores): Make store
likely.
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index
This patch fixes profile update after RTL unroll, that is now done same way as
in tree one. We still produce (slightly) corrupted profile for multiple exit
loops I can try to fix incrementally.
I also updated testcases to look for profile mismatches so they do not creep
back in again.
Hi,
This patch fixes profile update in tree_transform_and_unroll_loop which is used
by predictive comming. I stared by attempt to fix
gcc.dg/tree-ssa/update-unroll-1.c I xfailed last week, but it turned to be
harder job.
Unrolling was never fixed for changes in duplicate_loop_body_to_header_edge
Hi,
this fixes two bugs in tree-ssa-loop-im.cc. First is that cap probability is
not
reliable, but it is constructed with adjusted quality. Second is that sometimes
the conditional has wrong joiner BB count. This is visible on
testsuite/gcc.dg/pr102385.c however the testcase triggers another
Hi,
profile_count::apply_probability misses check for uninitialized
probability which leads to completely random results on applying
uninitialized probability to initialized scale. This can make
difference when i.e. inlining -fno-guess-branch-probability function to
-fguess-branch-probability
Hi,
this patch makes profile_count::to_sreal_scale consider the scale
unknown when in is 0. This fixes the case where loop has 0 executions
in profile feedback and thus we can't determine its trip count.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
gcc/ChangeLog:
*
> On Mon, Jul 17, 2023 at 12:36 PM Jan Hubicka via Gcc-patches
> wrote:
> >
> > Hi,
> > While looking into sphinx3 regression I noticed that vectorizer produces
> > BBs with overall probability count 120%. This patch fixes it.
> > Richi, I don't know how
Avoid scaling flat loop profiles of vectorized loops
As discussed, when vectorizing loop with static profile, it is not always good
idea
to divide the header frequency by vectorization factor because the profile may
not realistically represent the expected number of iterations. Since in such
Hi,
this patch fixes template in the two testcases so it matches the output
correctly. I did not re-test after last changes in the previous patch,
sorry for that.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/copy-headers-9.c: Fix template for
tree-ssa-loop-ch.cc changes.
*
Hi,
this patch adds maybe_flat_loop_profile which can be used in loop profile udpate
to detect situation where the profile may be unrealistically flat and should
not be dwonscalled after vectorizing, unrolling and other transforms that
assume that loop has high iteration count even if the CFG
Fix sreal::to_int and implement sreal::to_nearest_int
while exploring new loop estimate dumps, I noticed that loop iterating 1.8
times by profile is etimated as iterating once instead of 2 by nb_estimate.
While nb_estimate should really be a sreal and I will convert it incrementally,
I found
> > The patch requires bit of testsuite changes
> > - I disabled ch in loop-unswitch-17.c since it tests unswitching of
> >loop invariant conditional.
> > - pr103079.c needs ch disabled to trigger vrp situation it tests for
> >(otherwise we optimize stuff earlier and better)
> > -
Hi,
currently loop-ch skips all do-while loops. But when loop is not do-while
in addition to original goal of turining it to do-while it can do additional
things:
1) move out loop invariant computations
2) duplicate loop invariant conditionals and eliminate them in loop body.
3) prove that
Hi,
we have finite_p flag in loop structure. finite_loop_p already know to
use it, but we also may set the flag when we prove loop to be finite by
SCEV analysis to avoid duplicated work.
Bootstrapped/regtested x86_64-linux, OK?
gcc/ChangeLog:
* tree-ssa-loop-niter.cc (finite_loop_p):
Hi,
we have flow_loop_dump and print_loop. While print_loop was extended to dump
stuff from loop structure we added over years (loop info), flow_loop_dump was
not.
-fdump-tree-all files contains flow_loop_dump which makes it hard to see what
metadata we have attached to loop.
This patch unifies
Hi,
this patch cleanups API for determining expected loop iteraitons from profile.
We started with having expected_loop_iterations and only source was the integer
represented BB counts. It did some work on guessing number of iteration if
profile was absent or bogus. Later we introduced loop_info
> Tamar Christina writes:
> > Hi All,
> >
> > The resulting predicate register of a whilelo is not
> > restricted to the lower half of the predicate register file.
> >
> > As such these tests started failing after recent changes
> > because the whilelo outside the loop is getting assigned p15.
>
Hi,
this patch makes tree-ssa-loop-ch to understand if-combined conditionals (which
are quite common) and remove the IV-derived heuristics. That heuristics is
quite dubious because every variable with PHI in header of integral or pointer
type is seen as IV, so in the first basic block we match
> On Mon, Jul 17, 2023 at 12:36 PM Jan Hubicka via Gcc-patches
> wrote:
> >
> > Hi,
> > While looking into sphinx3 regression I noticed that vectorizer produces
> > BBs with overall probability count 120%. This patch fixes it.
> > Richi, I don't know how
Hi,
try_peel_loop uses gimple_duplicate_loop_body_to_header_edge which subtracts
the profile
from the original loop. However then it tries to scale the profile in a wrong
way
(it forces header count to be entry count).
This eliminates to profile misupdates in the internal loop of sphinx3.
Hi,
when vectorizing 4 times, we sometimes do
for
<4x vectorized body>
for
<2x vectorized body>
for
<1x vectorized body>
Here the second two fors handling epilogue never iterates.
Currently vecotrizer thinks that the middle for itrates twice.
This turns out to be
Hi,
While looking into sphinx3 regression I noticed that vectorizer produces
BBs with overall probability count 120%. This patch fixes it.
Richi, I don't know how to create a testcase, but having one would
be nice.
Bootstrapped/regtested x86_64-linux, commited last night (sorry for
late email)
Hi,
currently we rebuild profile_counts from profile_probability after inlining,
because there is a chance that producing large loop nests may get
unrealistically
large profile_count values. This is much less of concern when we switched to
new profile_count representation while back.
This
Hi,
loop-ch currently does analysis using ranger for all loops to identify
candidates and then follows by phase where headers are duplicated (which
breaks SSA and ranger). The second stage does more analysis (to see how
many BBs we want to duplicate) but can't use ranger and thus misses
Hi,
as discussed this patch moves profile updating to tree-ssa-loop-ch.cc since it
is
now quite ch specific. There are no functional changes.
Boostrapped/regtesed x86_64-linux, comitted.
gcc/ChangeLog:
* tree-cfg.cc (gimple_duplicate_sese_region): Rename to ...
> > > When a function doesn't contain calls to
> > > unknown functions we can be a bit more lenient: we can make it so that
> > > GCC simply doesn't touch xmm8-15 at all, then no save/restore is
> > > necessary.
One may also take into account that first 8 registers are cheaper to
encode than the
Hi,
this patch improves profile update in loop-ch to handle situation where
duplicated header
has loop invariant test. In this case we konw that all count of the exit edge
belongs to
the duplicated loop header edge and can update probabilities accordingly.
Since we also do all the work to track
> > By now we did CCP and FRE so we likely optimized out most of constant
> > conditionals exposed by inline.
>
> So maybe we should simply delay re-propagation of the profile? I
> think cunrolli doesn't so much care about the profile - cunrolli
> is (was) about abstraction removal. Jump
>
> What I saw most wrecking the profile is when passes turn
> if (cond) into if (0/1) leaving the CFG adjustment to CFG cleanup
> which then simply deletes one of the outgoing edges without doing
> anything to the (guessed) profile.
Yep, I agree that this is disturbing. At the cfg cleanup time
> > > FWIW, this particular patch was regstrapped on x86-64-linux
> > > with trunk from a week ago (and sniff-tested on current trunk).
> >
> > This looks really cool.
>
> The biggest benefit might be from IPA with LTO where we'd carefully place
> those
> attributes at WPA time (at that time
> On Fri, 7 Jul 2023, Jan Hubicka wrote:
>
> > >
> > > Looks good, but I wonder what we can do to at least make the
> > > multiple exit case behave reasonably? The vectorizer keeps track
> >
> > > of a "canonical" exit, would it be possible to pass in the main
> > > exit edge and use that
Hi,
over weekend I found that vectorizer is missing scale_loop_profile for
epilogues. It already adjusts loop_info to set max iteraitons, so
adding it was easy. However now predicts the first loop to iterate at
most once (which is too much, I suppose it forgets to divide by epilogue
unrolling
Hi,
dumps of profile_counts are quite hard to interpret since they are 64bit fixed
point
values. In many cases one looks at a single function and it is better to think
of
basic block frequency, that is how many times it is executed each invocatoin.
This
patch makes CFG dumps to also print this
Hi,
I forgot to check dump_file being non-NULL before writting to it.
It is somewhat odd that this does not trigger more often - I will take
deeper look tomorrow, but I am checking this in as obvious to avoid ICE.
Honza
gcc/ChangeLog:
PR tree-optimization/110600
*
Fix tree-ssa/update-cunroll.c
In this testcase the profile is misupdated before loop has two exits.
The first exit is one eliminated by complete unrolling while second exit
remains.
We remove first exit but forget about fact that the source BB of other exit will
then have higher frequency making
Hi,
we can use the new set_edge_probability_and_rescale_others here.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
gcc/ChangeLog:
* predict.cc (force_edge_cold): Use
set_edge_probability_and_rescale_others; improve dumps.
diff --git a/gcc/predict.cc b/gcc/predict.cc
Hi,
Information about profile mismatches is printed only with -details-blocks for
some time.
I think it should be printed even with default to make it easier to spot when
someone introduces
new transform that breaks the profile, but I will send separate RFC for that.
This patch enables details
> Hi Both,
>
> Thanks for all the reviews/patches so far
>
> > >
> > > Looks good, but I wonder what we can do to at least make the multiple
> > > exit case behave reasonably? The vectorizer keeps track
> >
> > > of a "canonical" exit, would it be possible to pass in the main exit
> > > edge
>
> Looks good, but I wonder what we can do to at least make the
> multiple exit case behave reasonably? The vectorizer keeps track
> of a "canonical" exit, would it be possible to pass in the main
> exit edge and use that instead of single_exit (), would other
> exits then behave somewhat
Hi,
this patch makes loop-ch and loop unrolling to fix profile in case the loop is
known to not iterate at all (or iterate few times) while profile claims it
iterates more. While this is kind of symptomatic fix, it is best we can do
incase profile was originally esitmated incorrectly.
In the
Hi,
original scale_loop_profile was implemented to only handle very simple loops
produced by vectorizer at that time (basically loops with only one exit and no
subloops). It also has not been updated to new profile-count API very carefully.
Since I want to use it from loop peeling and unlooping, I
Hi,
this patch applies some TLC to update_bb_profile_for_threading. The function
resales
probabilities by:
FOR_EACH_EDGE (c, ei, bb->succs)
c->probability /= prob;
which is correct but in case prob is 0 (took all execution counts to the newly
constructed path), this leads to
> On Wed, 28 Jun 2023, Tamar Christina wrote:
>
> > Hi All,
> >
> > There's an existing bug in loop frequency scaling where the if statement
> > checks
> > to see if there's a single exit, and records an dump file note but then
> > continues.
> >
> > It then tries to access the null pointer,
> The mod-subtract optimization with ncounts==1 produced incorrect edge
> probabilities due to incorrect conditional probability calculation. This
> patch fixes the calculation.
>
> gcc/ChangeLog:
>
> * value-prof.cc (gimple_mod_subtract_transform): Correct edge
> prob calculation.
Hi,
most common source of profile mismatches is now copyheader pass. The reason is
that
in comon case the duplicated header condition will become constant true and
that needs
changes in the loop exit condition probability.
While this can be done by jump threading it is not, since it gives up
Hi,
this patch fixes some of profile mismatches caused by profile updating.
It seems that I misupdated update_bb_profile_for_threading in 2017 which
results in invalid updates from rtl threading and threadbackwards.
update_bb_profile_for_threading knows that some paths to BB are being
redirected
Hi,
while looking into the std::vector _M_realloc_insert codegen I noticed that
call of __throw_bad_alloc is predicted with 10% probability. This is because
the conditional guarding it has __builtin_expect (cond, 0) on it. This
incorrectly takes precedence over more reliable heuristics
Compute ipa-predicates for conditionals involving __builtin_expect_p
std::vector allocator looks as follows:
__attribute__((nodiscard))
struct pair * std::__new_allocator
>::allocate (struct __new_allocator * const this, size_type __n, const void *
D.27753)
{
bool _1;
long int _2;
long
Hi,
early inliner currently skips always_inline functions and moreover we ignore
calls from always_inline in ipa_reverse_postorder. This leads to disabling
most of propagation done using early optimization that is quite bad when
early inline functions are not leaf functions, which is now quite
> I think the __throw_bad_alloc() and __throw_bad_array_new_length()
> functions should always be rare, so marking them cold seems fine (users who
> define their own allocators that want to throw bad_alloc "often" will
> probably throw it directly, they shouldn't be using our __throw_bad_alloc()
>
>
> On 6/27/23 12:24, Jan Hubicka wrote:
> > > On 6/27/23 09:19, Jan Hubicka wrote:
> > > > Hi,
> > > > as shown in the testcase (which would eventually be useful for
> > > > optimizing std::vector's push_back), ipa-prop can use context dependent
> > > > ranger
> > > > queries for better value
>
> On 6/27/23 09:19, Jan Hubicka wrote:
> > Hi,
> > as shown in the testcase (which would eventually be useful for
> > optimizing std::vector's push_back), ipa-prop can use context dependent
> > ranger
> > queries for better value range info.
> >
> > Bootstrapped/regtested x86_64-linux, OK?
>
Hi,
as shown in the testcase (which would eventually be useful for
optimizing std::vector's push_back), ipa-prop can use context dependent ranger
queries for better value range info.
Bootstrapped/regtested x86_64-linux, OK?
Honza
gcc/ChangeLog:
PR middle-end/110377
*
Hi,
playing with testcases for path isolation and const function, I noticed
that we do not seem to even try to isolate out of range array accesses:
int a[3]={0,1,2};
test(int i)
{
if (i > 3)
return test2(a[i]);
return a[i];
}
Here call to test2 is dead, since a[i] will
Hi,
compiling the testcase from PR109849 (which uses std:vector based stack to
drive a loop) with profile feedbakc leads to profile mismatches introduced by
tree-ssa-dce. This is the new code to produce unified forwarder blocks for
PHIs.
I am not including the testcase itself since
checking it
> > Also as discussed some time ago, the volatile loads between traps has
> > effect of turning previously pure/const functions into non-const which
> > is somewhat sad, so it is still on my todo list to change it this stage1
> > to something more careful. We discussed internal functions
> I intend to push this to trunk once testing finishes.
>
> I generated the diff with -b so the whitespace changes aren't shown,
> because there was some re-indenting that makes the diff look larger than
> it really is.
>
> Honza, I don't think this is likely to make much difference for the PR
>
Hi,
here is updated version with TODO_update_ssa_only_virtuals.
bootstrapped/regtested x86_64-linux. OK?
gcc/ChangeLog:
* tree-ssa-phiprop.cc (propagate_with_phi): Compute post dominators on
demand.
(pass_phiprop::execute): Do not compute it here; return
>
> So you need to feed it with extra info on the optimized out stmts because
> as-is it will not remove __builtin_unreachable (). That means you're
My plan was to add entry point to tree-ssa-dce that will take an
set of stmts declared dead by external force and will do the usual mark
stage
> >
> > gcc/ChangeLog:
> >
> > * builtins.cc (expand_builtin_fork_or_exec): Check
> > profile_condition_flag.
> > * collect2.cc (main): Add -fno-profile-conditions to OBSTACK.
> > * common.opt: Add new options -fprofile-conditions and
> > * doc/gcov.texi: Add --conditions
> On Mon, Jun 19, 2023 at 12:15 PM Jan Hubicka wrote:
> >
> > > On Mon, Jun 19, 2023 at 9:52 AM Jan Hubicka via Gcc-patches
> > > wrote:
> > > >
> > > > Hi,
> > > > this was suggested earlier somewhere, but I can not fin
>
>
> On 6/22/23 00:31, Richard Biener wrote:
> > I think there's a difference in that __builtin_trap () is observable
> > while __builtin_unreachable () is not and reaching __builtin_unreachable
> > () invokes undefined behavior while reaching __builtin_trap () does not.
> >
> > So the
>
> If I manually add a __builtin_unreachable () to the above case
> I see the *(int *)0 = 0; store DSEd. Maybe we should avoid
> removing stores that might trap here? POSIX wise such a trap
> could be a way to jump out of the path leading to unreachable ()
> via siglongjmp ...
I am not sure
> > >
> > > size_type
> > > _M_check_len(size_type __n, const char* __s) const
> > > {
> > > const size_type __size = size();
> > > const size_type __max_size = max_size();
> > >
> > > if (__is_same(allocator_type, allocator<_Tp>)
> > > &&
> >
> > size_type
> > _M_check_len(size_type __n, const char* __s) const
> > {
> > const size_type __size = size();
> > const size_type __max_size = max_size();
> >
> > if (__is_same(allocator_type, allocator<_Tp>)
> > && __size > __max_size
> On Mon, 19 Jun 2023 at 12:20, Jakub Jelinek wrote:
>
> > On Mon, Jun 19, 2023 at 01:05:36PM +0200, Jan Hubicka via Gcc-patches
> > wrote:
> > > - if (max_size() - size() < __n)
> > > - __throw_length_error(__N(__s));
> >
> > - if (max_size() - size() < __n)
> > - __throw_length_error(__N(__s));
> > + // On 64bit systems vectors of small sizes can not
> > + // reach overflow by growing by small sizes; before
> > + // this happens, we will run out of memory.
> > + if
1 - 100 of 403 matches
Mail list logo
