[PATCH] SimplifyCFG: turn recursive GatherConstantCompares into iterative

[Mehdi Amini]

> On Nov 17, 2014, at 1:48 PM, Michael Ilseman <milseman at apple.com> wrote:
> 
> +    V = DFT.back();
> +    DFT.pop_back();
> 
> V = DFT.pop_back_val();
> 
> +// one expected. If CurrValue is supplied, the return value has to be either
> +// nullptr or CurrValue
> ...
> +      // Try to match the current instruction
> +      if (Value *Matched = GatherConstantComparesMatch(I,
> +                                                       CurrValue,
> +                                                       Vals,
> +                                                       DL,
> +                                                       UsedICmps,
> +                                                       isEQ)) {
> +        // Match succeed, continue the loop
> +        CurrValue = Matched;
> 
> If that comment is true, then isn’t this assignment meaningless? That is, if the return is null then we’d never do the assignment. If the return is non-null, then it must be the same as the old CurrValue. Perhaps change this to an assert? If this is the case, then I wonder if GatherConstantComparesMatch shouldn’t just return a bool.

The first time GatherConstantComparesMatch is called, CurrValue is nullptr and we need to initialize CurrValue.
I can add an assert like :

assert(not CurrValue || CurrValue == Matched);

(but the assignment is still meaningful).

Mehdi



> 
> 
>> On Nov 17, 2014, at 1:40 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>> 
>> 
>>> On Nov 17, 2014, at 12:24 PM, Michael Ilseman <milseman at apple.com> wrote:
>>> 
>>> I like the change, but have a few minor comments:
>>> I would replace the stack with a SmallVector, as this code tends to return early once we start exceeding 8 entries (else the Span is too large).
>> 
>> It is not exactly the case, the limit for the Span is for a single comparison. We can have an infinite sequence of or/and chained.
>> However it is true that the common case it probably a short chain. So I replaced the stack with a SmallVector, but the vector of matched value (that will be turned as the cases of the switch) as well.
>> 
>> 
>>> 
>>> +// Try to match Instruction I as a comparison against a constant and populates
>>> +// Vals with the set of value that match (or does not depending on isEQ).
>>> +// Return nullptr on failure, or return the Value the comparison matched against
>>> +// on success
>>> +static Value* GatherConstantComparesMatch(Instruction *I,
>>> +                                          Value *CurrValue,
>>> 
>>> It took me a while of reading the code to realize what CurrValue as a parameter (as opposed to a return value) is for. You could briefly mention it in the comment before the function. It also seems like CurrValue, if set, will also always be the return value on success. Does it make sense to instead have that book-keeping be done in the caller of GatherConstantComparesMatch? Also, why does GatherConstantComparesMatch take in Extra? 
>> 
>> I add a comment, I can’t keep it out of the function because it changes the control flow inside.
>> I removed Extra, it was unused, well spotted!
>> 
>> Attached is the update patch.
>> 
>> <0001-SimplifyCFG-turn-recursive-GatherConstantCompares-in.patch>
>> 
>> 
>> Mehdi
>> 
>> 
>> 
>>> 
>>> 
>>>> On Nov 17, 2014, at 11:25 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> A long sequence of || or && of integer comparison against the same value is turned into a switch in SimplifyCFG.
>>>> 
>>>> The implementation was recursive and could lead to a stack explosion. I turned it into an iterative implementation in this patch.
>>>> 
>>>> As a side question, the existing code assumes that the “icmp" are always taking the constant as the second operand (it never tries to match the first operand). Is it something that is canonicalized in the IR and can be assumed here?
>>>> 
>>>> Thanks,
>>>> 
>>>> Mehdi
>>>> 
>>>> 
>>>> <0001-SimplifyCFG-turn-recursive-GatherConstantCompares-in.patch>_______________________________________________
>>>> llvm-commits mailing list
>>>> llvm-commits at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits