string methods intrinsics, place for checks

[Vladimir Kozlov]

Thanks Tom

Yes, I thought about combining assembler. I will do it.

Vladimir

Tom Rodriguez wrote:
> I think the boundaries you do look fine and the code looks good.  I 
> think the argument order for StrComp and StrIndexOf should be based on 
> the pairs, s1 c2 s2 c2, instead of pointers then counts.  Otherwise it 
> looks good.
> 
> Any chance the x86 assembly could be moved out of the ad file into the 
> shared part of assembler_x86?  The code is almost exactly the same at 
> least for StringEquals and StrComp and the differences could be papered 
> over easily.  Having one copy seems better.
> 
> tom
> 
> On Aug 18, 2009, at 7:15 PM, Vladimir Kozlov wrote:
> 
>> Tom Rodriguez wrote:
>>> If you mean constant folding the loads of the final fields of a 
>>> Constant string, I've got some changes for that coming.
>>
>> Yes, I meant that.
>>
>> And here is the first draft for string intrinsics changes:
>>
>> http://cr.openjdk.java.net/~kvn/6827605/webrev.00
>>
>> Vladimir
>>
>>> tom
>>> On Aug 18, 2009, at 4:10 PM, Vladimir Kozlov wrote:
>>>> I will send first draft tomorrow so you will see.
>>>>
>>>> An other question: should I add the check for argument->is_Con()
>>>> (string constant) and load argument's parameters statically
>>>> (as we do in indexOf intrinsic on not SSE42 path)?
>>>>
>>>> Or should I add the ideal optimization?
>>>>
>>>> Currently ideal optimizations do not convert loadI(AddP(ConP, 28))
>>>> to static load.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> Tom Rodriguez wrote:
>>>>> I don't know that there's a clear place to draw the line.  I'd tend 
>>>>> towards writing things in ideal if possible since that exposes it 
>>>>> to optimization and reduces the amount of assembly.  I'd probably 
>>>>> have a stronger opinion about a more concrete example.
>>>>> tom
>>>>> On Aug 18, 2009, at 2:35 PM, Vladimir Kozlov wrote:
>>>>>> I am modifying our string intrinsics to pass char[] pointers and
>>>>>> counters instead of string oops to allow EA eliminate non-escaping
>>>>>> string object (6827605). This will also allow to do some checks
>>>>>> in ideal graph instead of in a mach node encoding. But it may affect
>>>>>> ideal optimizations since it may complicate control flow.
>>>>>>
>>>>>> So I need your opinion where I should draw the line.
>>>>>>
>>>>>> For example, for String.equals() I compare counters in ideal but
>>>>>> check it for 0 in mach (mach node needs only one counter) since
>>>>>> == 0 is rare case.
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>>>
>