[PATCH] SimplifyCFG: turn recursive GatherConstantCompares into iterative

Michael Ilseman milseman at apple.com
Wed Nov 19 10:43:35 PST 2014


+    V = DFT.back();
+    DFT.pop_back();

You can also use "V = DFT.pop_back_val();"

Go ahead and commit the first patch with that change, so that we can stop exploding the stack.

For the second patch:

+// Return false on failure. On succes, the Value the comparison matched against

s/succes/success

+// Results.Vals with the set of value that match (or doesn't depending on isEQ).
+// Return false on failure. On succes, the Value the comparison matched against
+// is place in Result.CompValue.
+// If Result.CompValue is already used, the function is expected to fail if a
+// match is found but the value compared to is not the one expected.
+bool GatherConstantComparesMatch(Instruction *I, const DataLayout *DL,
+                                 bool isEQ,
+                                 GatherConstantComparesResult &Result) {

Seems like this should be a method on the GatherConstantComparesResult struct, as it’s just adjusting the struct’s state.

+bool GatherConstantComparesMatch(Instruction *I, const DataLayout *DL,

Similarly here.

How about we call the struct something like ConstantComparesGatherer, and it has methods called “match” and “gather”, or else something more descriptive. Without the “ConstantComparesGather*” redundancy, we can make the mehod names clearer.



> On Nov 17, 2014, at 8:17 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
> 
> Here is the patch updated without the #include <stack>
> 
> Bonus is the second patch to implement the refactor you suggested.
> 
> Mehdi
> 
> 
> <0001-SimplifyCFG-turn-recursive-GatherConstantCompares-in.patch>
> <0002-SimplifyCFG-Refactor-GatherConstantCompares-result-i.patch>
> 
>> On Nov 17, 2014, at 1:59 PM, Michael Ilseman <milseman at apple.com <mailto:milseman at apple.com>> wrote:
>> 
>> Ah, of course. Drop the "#include <stack>” and the patch LGTM. You could also consider refactoring into a class to track all the state that’s flying around in a subsequent commit, but I’m glad the stack-explosion problem is addressed.
>> 
>> 
>>> On Nov 17, 2014, at 1:51 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote:
>>> 
>>>> 
>>>> On Nov 17, 2014, at 1:48 PM, Michael Ilseman <milseman at apple.com <mailto: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 <mailto:mehdi.amini at apple.com>> wrote:
>>>>> 
>>>>> 
>>>>>> On Nov 17, 2014, at 12:24 PM, Michael Ilseman <milseman at apple.com <mailto: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 <mailto: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 <mailto:llvm-commits at cs.uiuc.edu>
>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits <http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141119/8a9a829b/attachment.html>


More information about the llvm-commits mailing list