Re: [PATCH] Fix illegal cast to rtx (*insn_gen_fn) (rtx, ...)
Stefan Kristiansson writes: > You mean something like this? Yes, that's what I had in mind. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: [PATCH] Fix pr57637
> Shrink-wrap optimization sinks some instructions for more > opportunities. It uses DF_LR_BB_INFO (bb)->def to check whether BB > clobbers SRC. But for ARM, gcc might generate cond_exec insns before > shrink-wrapping. And DF_LR_BB_INFO (bb)->def does not include def info > from cond_exec insns. So the check in function > move_insn_for_shrink_wrap is not enough. Posting a testcase would be even better, but the analysis looks plausible. DF_REF_CONDITIONAL and DF_REF_PARTIAL defs aren't killing defs so they are not included in the def set for LR. As you pointed out, they are included in the gen set for LIVE if it exists, so I guess we should wonder if we really want to do the scanning if LIVE doesn't exist, i.e. at -O1, instead of simply giving up. In any case, the scanning doesn't need to be redundant with the previous work, so: if (!(DF_REF_FLAGS (def) & (DF_REF_PARTIAL | DF_REF_CONDITIONAL))) continue; is missing in the patch. -- Eric Botcazou
RE: [PATCH][ARM][10/n] Partial IT block deprecation in ARMv8 AArch32 - thumb2.md changes
Hi Richard, > (define_insn_and_split "*thumb2_smaxsi3" > - [(set (match_operand:SI 0 "s_register_operand" "=r,r,r") > - (smax:SI (match_operand:SI 1 "s_register_operand" "0,r,?r") > - (match_operand:SI 2 "arm_rhs_operand""rI,0,rI"))) > + [(set (match_operand:SI 0 "s_register_operand" "=r,r,r ,r,l") > + (smax:SI (match_operand:SI 1 "s_register_operand" "0,r,?r,0,0") > + (match_operand:SI 2 "arm_rhs_operand""rI,0,rI,r,Py"))) > (clobber (reg:CC CC_REGNUM))] > > min/max operations are commutative. Marking this pattern as such would > make the second alternative redundant. Furthermore, splitting the first > pattern into a register only variant and an immediate variant would mean > you don't then need one of your additional alternatives later on. I > think you want constraints of the form > > op0: "=r,l,r,r" > op1: "%0,0,0,r" > op2: "r,Py,I,r" > > This has the added advantage that you can now get a more accurate length > calculation for the first two cases. > > Similarly for the other min/max operations. Done, I've also converted the splitters to generate cond_execs instead of if_then_else to make it more explicit that we expect one conditional move from this pattern. > > (define_insn_and_split "*thumb2_abssi2" > - [(set (match_operand:SI 0 "s_register_operand" "=r,&r") > + [(set (match_operand:SI 0 "s_register_operand" "=Ts,&r") > (abs:SI (match_operand:SI 1 "s_register_operand" "0,r"))) > > I think this pattern should be reworked to put the second alternative > first. In thumb state that will be more efficient (two instructions > rather than three). There's also now an argument for splitting out the > 'l' and 'r' alteratives of the current 'it' variant and giving more > accurate length costs for the two. > > Likewise for thumb2_neg_abssi2. Done. > > (define_insn_and_split "*thumb2_mov_scc" > - [(set (match_operand:SI 0 "s_register_operand" "=r") > + [(set (match_operand:SI 0 "s_register_operand" "=r, =l") > > '=' applies to all the alternatives. Only put it at the start of the > constraint string. > > Also applies to thumb2_mov_negscc. Done. > > (define_insn_and_split "*thumb2_mov_notscc" > [(set (match_operand:SI 0 "s_register_operand" "=r") > (not:SI (match_operator:SI 1 "arm_comparison_operator" >[(match_operand 2 "cc_register" "") (const_int 0)])))] > - "TARGET_THUMB2" > + "TARGET_THUMB2 && !arm_restrict_it" > > For restricted IT and low regs, this could be reworked as > > mvn rd, #0 > it > lsl rd, rd, #1 > Reworked splitter. > +(define_insn "*thumb2_ior_scc_strict_it" > + [(set (match_operand:SI 0 "s_register_operand" "=l,=l") > > Repeated '=' Fixed. Is this better? Tested on model --with-arch=armv8-a with and without -mthumb. Bootstrapped on a Cortex-A15. Thanks, Kyrill 2013-07-11 Kyrylo Tkachov * config/arm/predicates.md (shiftable_operator_strict_it): New predicate. * config/arm/thumb2.md (thumb_andsi_not_shiftsi_si): Disable cond_exec version for arm_restrict_it. (thumb2_smaxsi3): Convert to generate cond_exec. (thumb2_sminsi3): Likewise. (thumb32_umaxsi3): Likewise. (thumb2_uminsi3): Likewise. (thumb2_abssi2): Adjust constraints for arm_restrict_it. (thumb2_neg_abssi2): Likewise. (thumb2_mov_scc): Add alternative for 16-bit encoding. (thumb2_movsicc_insn): Adjust alternatives. (thumb2_mov_negscc): Disable for arm_restrict_it. (thumb2_mov_negscc_strict_it): New pattern. (thumb2_mov_notscc_strict_it): New pattern. (thumb2_mov_notscc): Disable for arm_restrict_it. (thumb2_ior_scc): Likewise. (thumb2_ior_scc_strict_it): New pattern. (thumb2_cond_move): Adjust for arm_restrict_it. (thumb2_cond_arith): Disable for arm_restrict_it. (thumb2_cond_arith_strict_it): New pattern. (thumb2_cond_sub): Adjust for arm_restrict_it. (thumb2_movcond): Likewise. (thumb2_extendqisi_v6): Disable cond_exec variant for arm_restrict_it. (thumb2_zero_extendhisi2_v6): Likewise. (thumb2_zero_extendqisi2_v6): Likewise. (orsi_notsi_si): Likewise. (orsi_not_shiftsi_si): Likewise. 11-thumb2-changes.patch Description: Binary data
Re: [c++-concepts] requires expression semantics
On 07/10/2013 08:24 AM, Andrew Sutton wrote: That's a good idea. I changed every existing use of can_convert to can_convert_standard for the time being. That will preserve the existing behavior, and we can determine which of the existing uses can include user-defined conversions later. Let's leave alone cases where we know the arguments are non-class types, and only build the CAST_EXPR if one of the types is a class. And you don't need is_reference_to_function_type anymore. +// Returns a type that suitable to be used as an rvalue of type T. +// Except for function types, this is the same as T. For function +// types, this is an rvalue reference to T. To be pedantic, describing it as an rvalue of type T isn't exactly right; the reason we need to do this for functions is that an rvalue reference to function produces an lvalue, whereas all other rvalue references produce xvalues. Go ahead and apply the patch with those tweaks. Jason
Re: [C++14/lambda] Experimental polymorphic lambda patches
On 07/01/2013 04:26 PM, Adam Butcher wrote: I've finally reworked the generic lambda patches I made back in 2009 (http://gcc.1065356.n5.nabble.com/lambda-Latest-experimental-polymorphic-lambda-patches-tt713016.html) to apply against GCC's mainline. Great! Missing features: - Conversion to function pointer of stateless generic lambdas is currently unsupported. Currently a warning is generated for all such lambdas at their definition. Other issues: (see XXX, FIXME, TODO) a) Location of implementation. Let's move all the lambda code into a new lambda.c, semantics.c has gotten huge. b) What to do about name mangling? I think what you have already should do the right thing; for normal function template instantiations we mangle the uninstantiated type of the template along with the template arguments, so I think for a generic lambda just mangling the uninstantiated parameter types is the way to go. Any comments appreciated. Guidance on implementing the conversion operator for stateless generic lambdas would be useful. I've made a few attempts which were lacking! It seemed to me that N3649's description of the semantics should translate pretty easily into an implementation. What problems are you running into? + Couldn't figure out a clean way to test for lambda inside + check_member_template. */ LAMBDA_TYPE_P (current_class_type) doesn't work? fn = lambda_function (closure); + if (TREE_CODE (fn) == TEMPLATE_DECL) +fn = DECL_TEMPLATE_RESULT (fn); I think you could use STRIP_TEMPLATE before returning from lambda_function so that we don't need to adjust all the callers to deal with stripping the template, so instead of -lambda = BASELINK_FUNCTIONS (lambda); +lambda = OVL_CURRENT (BASELINK_FUNCTIONS (lambda)); You could have lambda = STRIP_TEMPLATE (get_first_fn (lambda)); + if (TREE_CODE (d) == TEMPLATE_DECL) +return d; Instead of this, let's avoid calling instantiate_decl from instantiate_class_template_1. e) Should collect 'auto' parameters during parse and realloc template parameter list once at the end of the parameter list rather than incrementally. I agree, I don't think you need to do anything special while parsing the parameter list. Jason
Re: [PATCH 5/6] Andes nds32: documentation for nds32 target.
On 7/10/13 8:11 AM, Joseph S. Myers wrote:
Don't you have built-in functions to document as well?
You are right.
We did forget to describe built-in functions in the documentation.
Thanks for pointing out our carelessness. :)
Use "@:" (or a comma) after "i.e." in Texinfo sources. The range "16-47"
should use an en dash (so "16--47").
Fixed accordingly.
Thanks for the review comments. A revised patch is provided
and the issues you mentioned are fixed:
a. Describe nds32 built-in functions.
b. Use "@:" and "16--47"
A plain text ChangeLog is revised as well:
gcc/
2013-07-12 Chung-Ju Wu
Shiva Chen
* doc/invoke.texi (NDS32 Options): Document nds32 specific options.
* doc/md.texi (Constraints for Particular Machines): Document
nds32 specific constraints.
* doc/install.texi (Cross-Compiler-Specific Options): Document
--with-nds32-lib for nds32 target.
* doc/extend.texi (Declaring Attributes of Functions,
NDS32 Built-in Functions): Document nds32 specific attributes and
built-in functions.
In addition, for your other review comments:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00388.html
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00390.html
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00391.html
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00394.html
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00395.html
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00396.html
those are very helpful and we are now working on them.
The corresponding revised patches will be provided once we complete it.
Thank you for your great help. :)
Best regards,
jasonwucj
diff --git gcc/doc/extend.texi gcc/doc/extend.texi
index 1c85a3e..e1f31a1 100644
--- gcc/doc/extend.texi
+++ gcc/doc/extend.texi
@@ -2502,6 +2502,12 @@ on data in the eight-bit data area. Note the eight-bit
data area is limited to
You must use GAS and GLD from GNU binutils version 2.7 or later for
this attribute to work correctly.
+@item exception
+@cindex exception handler functions
+Use this attribute on the NDS32 target to indicate that the specified function
+is an exception handler. The compiler will generate corresponding sections
+for use in an exception handler.
+
@item exception_handler
@cindex exception handler functions on the Blackfin processor
Use this attribute on the Blackfin to indicate that the specified function
@@ -2922,6 +2928,32 @@ void __attribute__ ((interrupt, use_shadow_register_set,
use_debug_exception_return)) v7 ();
@end smallexample
+On NDS32 target, this attribute is to indicate that the specified function
+is an interrupt handler. The compiler will generate corresponding sections
+for use in an interrupt handler. You can use the following attributes
+to modify the behavior:
+@table @code
+@item nested
+@cindex @code{nested} attribute
+This interrupt service routine is interruptible.
+@item not_nested
+@cindex @code{not_nested} attribute
+This interrupt service routine is not interruptible.
+@item nested_ready
+@cindex @code{nested_ready} attribute
+This interrupt service routine is interruptible after @code{PSW.GIE}
+(global interrupt enable) is set. This allows interrupt service routine to
+finish some short critical code before enabling interrupts.
+@item save_all
+@cindex @code{save_all} attribute
+The system will help save all registers into stack before entering
+interrupt handler.
+@item partial_save
+@cindex @code{partial_save} attribute
+The system will help save caller registers into stack before entering
+interrupt handler.
+@end table
+
On RL78, use @code{brk_interrupt} instead of @code{interrupt} for
handlers intended to be used with the @code{BRK} opcode (i.e.@: those
that must end with @code{RETB} instead of @code{RETI}).
@@ -3143,10 +3175,11 @@ and newer.
@item naked
@cindex function without a prologue/epilogue code
-Use this attribute on the ARM, AVR, MCORE, RL78, RX and SPU ports to indicate
that
-the specified function does not need prologue/epilogue sequences generated by
-the compiler. It is up to the programmer to provide these sequences. The
-only statements that can be safely included in naked functions are
+Use this attribute on the ARM, AVR, MCORE, NDS32, RL78, RX and SPU ports
+to indicate that the specified function does not need prologue/epilogue
+sequences generated by the compiler.
+It is up to the programmer to provide these sequences.
+The only statements that can be safely included in naked functions are
@code{asm} statements that do not have operands. All other statements,
including declarations of local variables, @code{if} statements, and so
forth, should be avoided. Naked functions should be used to implement the
@@ -3491,6 +3524,21 @@ safe since the loaders there save EAX, EDX and ECX.
(Lazy binding can be
disabled with the linker or the loader if desired, to avoid the
problem.)
+@item reset
+@cindex reset handler functions
+Use t
Re: [PATCH] PR57792: Bootstrap darwin13 or later with --with-sysroot to find SDK
On Jul 10, 2013, at 7:05 PM, Jack Howarth wrote: > Current gcc trunk now builds fine on darwin13. Thanks for the commit. Thanks the checking (and the work).
New Finnish PO file for 'gcc' (version 4.8.0)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Finnish team of translators. The file is available at: http://translationproject.org/latest/gcc/fi.po (This file, 'gcc-4.8.0.fi.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: MIPS elimate trap-if-zero instruction if possible for divisions
Graham Stott writes:
> Not sure if that working.
>
> I created some rtl using TRAP_IF to represent the TEQ and emiited via an
> expander
>
> The TRAP_IF rtl make ait all the way though the rtl optimizers which are
> run after expand
> even though it should be possible to determine is false.
>
>
> (insn 7 3 20 2 (set (reg:SI 2 $2 [201])
> (const_int 27 [0x1b])) bug.c:67 289 {*movsi_internal}
> (expr_list:REG_EQUIV (const_int 27 [0x1b])
> (nil)))
>
> (insn 20 7 21 2 (trap_if (eq:SI (reg:SI 2 $2 [201])
> (const_int 0 [0]))
> (const_int 7 [0x7])) bug.c:68 8 {*conditional_trapNsi_if_zero}
> (nil))
>
> I grepped the RTL code for any code handling TRAP_IF that looked like it
> might remove the TRAP_IF but
> only found some code is final_scan which only applied to CC0 backends.
>
> Is using a conditional trap (TRAP_IF) the right way to go?
For TEQ, yes, but perhaps we don't optimise TRAP_IF as much as branches.
Have you already tried the -mmdivide-breaks version too, which I think
ought to be a separate branch and trap at the rtl level? Does the branch
get optimised away? If so, perhaps we should extend that pass to handle
TRAP_IF too. (I'm being deliberately vague because I'm not sure without
trying it myself whether cse, combine, or something else is likely to
catch it first. But there is rtl code to track nonzeroness, so I'd be
surprised if every pass missed it.)
Thanks,
Richard
Re: [patch, mips] Size optimization for MIPS
Steve Ellcey writes: > On Tue, 2013-07-09 at 18:25 +0100, Richard Sandiford wrote: >> That was always the case though. These registers weren't enabled because >> you can do operations on them. They were enabled because they should make >> ideal spill space. Moves to and from these registers always take 2 bytes, >> whereas stack spills take either 2 or 4 bytes (as well as being slower). >> >> So it sounds like the problem is that the heuristics aren't tuned properly. >> Disabling the registers seems like papering over the problem rather than >> fixing it. But since no-one is likely to do the work to fix the heuristics, >> that isn't a good enough reason to reject the patch. > > Pre-LRA I don't think there was any good way to tell GCC to use a > register for reloads but not for anything else. I think LRA does > support this and someone here has started looking at LRA but we haven't > come up with register class definitions that make LRA work better then > the existing setup (particularly in terms of MIPS16 object size). Do > you know if anyone else has started looking at LRA on MIPS? No. I should be doing it myself, sorry, but I've got distracted by binutils stuff recently. Glad to hear someone's looking at it. It isn't necessarily just classes that need to change though. Things like the register move costs might need tweaking too. > + and $25 (t9) because it is used as the SVR4 PIC register. */ ...as the function call address in SVR4 PIC. Also, please make sure that the comment consistently uses tabs (sorry). Some lines were indented purely with spaces. OK with that change, thanks. Richard
[PATCH] Invoke ggc_free to free vec being released
This patch adds a call to ggc_free from va_gc::release, which is
called by vec_free. This was a regression from the old VEC_free
implementation and reduces the memory footprint during compilation.
Bootstrapped and tested on x86_64-unknown-linux-gnu. Ok for trunk?
2013-07-11 Teresa Johnson
* vec.h (struct va_gc): Move release out-of-line.
(va_gc::release): Call ggc_free on released vec.
Index: vec.h
===
--- vec.h (revision 200906)
+++ vec.h (working copy)
@@ -337,10 +337,22 @@ struct va_gc
CXX_MEM_STAT_INFO);
template
- static void release (vec *&v) { v = NULL; }
+ static void release (vec *&v);
};
+/* Free GC memory used by V and reset V to NULL. */
+
+template
+inline void
+va_gc::release (vec *&v)
+{
+ if (v)
+::ggc_free (v);
+ v = NULL;
+}
+
+
/* Allocator for GC memory. Ensure there are at least RESERVE free
slots in V. If EXACT is true, grow exactly, else grow
exponentially. As a special case, if the vector had not been
--
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
Re: [PATCH] Invoke ggc_free to free vec being released
On Thu, Jul 11, 2013 at 2:24 PM, Teresa Johnson wrote: > 2013-07-11 Teresa Johnson > > * vec.h (struct va_gc): Move release out-of-line. > (va_gc::release): Call ggc_free on released vec. OK. Thanks. Diego.
[c++-concepts] requires expressions
The attached patch finishes the semantics for requires expressions. It includes reduction rules for constraint decomposition, substitution rules, and diagnostics. Andrew Changelog: 2013-07-11 Andrew Sutton * gcc/cp/cp-tree.h (declare_local_parms): New * gcc/cp/cp-tree.h (finish_validtype_expr): Fixed typo. * gcc/cp/semantics.c (potential_constant_expr): Return true for requirements. (finish_requires_expr): Actually evaluate when we are not processing a template decl. * pt.c (tsubst_requires_expr): New, along with helper functions for instantiating requires parameters. (tsubst_validexpr_expr): New. (tsubst_validtype_expr): New. (tsubst_constexpr_expr): New. (tsubst_expr_req): New. (tsubst_type_req): New. (tsubst_nested_req): New. (tsubst_copy_and_build): Substitution rules for requirements. (instantiate_requirements): Do not require a constant expression. * constraint.cc (redcue_requires): Reduction rules for requires expressions and requirement nodes. (reduce_stmt_list): Remove redundant checks. (diagnose_requires): Diagnose failures in requires expressions and specific kinds of expressions. * gcc/cp/cxx-pretty-print.c (pp_cxx_primary_expression): Pretty print expressions related to requirements (pp_cxx_requirement_parameter_list). Clean up implementation. * gcc/cp/cxx-pretty-print.h (pp_cxx_requirement_parameter_list): New, along with pretty printers for requirements-related expressions. * gcc/cp/error.c (dump_expr): Dump expressions related to requirements. (reqparms_to_string): New. (cp_printer): Use %Z to print a list of parameters. reqexpr-6.patch Description: Binary data
Re: [C++14/lambda] Experimental polymorphic lambda patches
On Wed, Jul 10, 2013 at 9:35 PM, Jason Merrill wrote: > Let's move all the lambda code into a new lambda.c, semantics.c has gotten > huge. Amen to that, brother! -- Gaby
RE: FW: [PATCH GCC]Relax the probability condition in CE pass when optimizing for code size
> -Original Message-
> From: Eric Botcazou [mailto:ebotca...@adacore.com]
> Sent: Wednesday, July 10, 2013 5:06 PM
> To: Bin Cheng
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: FW: [PATCH GCC]Relax the probability condition in CE pass
when
> optimizing for code size
>
> > 2013-03-25 Bin Cheng
> >
> > * ifcvt.c (ifcvt_after_combine): New static variable.
> > (cheap_bb_rtx_cost_p): Set scale to REG_BR_PROB_BASE when optimizing
> > for size.
> > (rest_of_handle_if_conversion, rest_of_handle_if_after_combine):
> > Clear/set the variable ifcvt_after_combine.
>
> The idea looks sensible. Some remarks:
> - add an after_combine parameter to if_convert and set the global from
within
> this function instead of the pass functions (True, not TRUE, in the
comment).
> - explain in the comment why you use optimize_function_for_speed_p
instead of
> the 'speed' variable defined just above in cheap_bb_rtx_cost_p,
> - set the 'scale' variable only once in cheap_bb_rtx_cost_p (otherwise
this
> is gratuitously confusing) and explain in the comment the reasoning for
> choosing REG_BR_PROB_BASE in the !speed case (I presume it's to void the
> identical scaling applied to the insns of the block).
>
Thanks Eric, I updated the patch incorporating your comments. Also retested
on x86/thumb2 with both normal and Os.
Is it OK?
Thanks.
bin
2013-07-12 Bin Cheng
* ifcvt.c (ifcvt_after_combine): New static variable.
(cheap_bb_rtx_cost_p): Set scale to REG_BR_PROB_BASE when optimizing
for size.
(if_convert): New parameter after_combine. Set ifcvt_after_combine.
(rest_of_handle_if_conversion, rest_of_handle_if_after_combine,
rest_of_handle_if_after_reload): Pass new argument for if_convert.Index: gcc/ifcvt.c
===
--- gcc/ifcvt.c (revision 200774)
+++ gcc/ifcvt.c (working copy)
@@ -67,6 +67,9 @@
#define NULL_BLOCK ((basic_block) NULL)
+/* True if after combine pass. */
+static bool ifcvt_after_combine;
+
/* # of IF-THEN or IF-THEN-ELSE blocks we looked at */
static int num_possible_if_blocks;
@@ -141,11 +144,24 @@ cheap_bb_rtx_cost_p (const_basic_block bb, int sca
rtx insn = BB_HEAD (bb);
bool speed = optimize_bb_for_speed_p (bb);
+ /* Set scale to REG_BR_PROB_BASE to void the identical scaling
+ applied to insn_rtx_cost when optimizing for size. Only do
+ this after combine because if-conversion might interfer with
+ passes before combine.
+
+ Use optimize_function_for_speed_p instead of the pre-defined
+ variable speed to make sure it is set to same value for all
+ basic blocks in one if-conversion transformation. */
+ if (!optimize_function_for_speed_p (cfun) && ifcvt_after_combine)
+scale = REG_BR_PROB_BASE;
/* Our branch probability/scaling factors are just estimates and don't
account for cases where we can get speculation for free and other
secondary benefits. So we fudge the scale factor to make speculating
- appear a little more profitable. */
- scale += REG_BR_PROB_BASE / 8;
+ appear a little more profitable when optimizing for performance. */
+ else
+scale += REG_BR_PROB_BASE / 8;
+
+
max_cost *= scale;
while (1)
@@ -4337,10 +4353,11 @@ dead_or_predicable (basic_block test_bb, basic_blo
return FALSE;
}
-/* Main entry point for all if-conversion. */
+/* Main entry point for all if-conversion. AFTER_COMBINE is true if
+ we are after combine pass. */
static void
-if_convert (void)
+if_convert (bool after_combine)
{
basic_block bb;
int pass;
@@ -4351,6 +4368,8 @@ static void
df_live_set_all_dirty ();
}
+ /* Record whether we are after combine pass. */
+ ifcvt_after_combine = after_combine;
num_possible_if_blocks = 0;
num_updated_if_blocks = 0;
num_true_changes = 0;
@@ -4454,7 +4473,7 @@ rest_of_handle_if_conversion (void)
dump_flow_info (dump_file, dump_flags);
}
cleanup_cfg (CLEANUP_EXPENSIVE);
- if_convert ();
+ if_convert (false);
}
cleanup_cfg (0);
@@ -4495,7 +4514,7 @@ gate_handle_if_after_combine (void)
static unsigned int
rest_of_handle_if_after_combine (void)
{
- if_convert ();
+ if_convert (true);
return 0;
}
@@ -4530,7 +4549,7 @@ gate_handle_if_after_reload (void)
static unsigned int
rest_of_handle_if_after_reload (void)
{
- if_convert ();
+ if_convert (true);
return 0;
}
