I think yes. I'm going to test and provide the next patch on Monday. It will enable JET for all methods without double ops.
On 4/21/07, Nathan Beyer <[EMAIL PROTECTED]> wrote:
I'm fine with limiting this patch and setting up the next steps. Should we create some JIRAs for those steps? -Nathan On 4/20/07, Mikhail Fursov <[EMAIL PROTECTED]> wrote: > On 4/21/07, Rana Dasgupta <[EMAIL PROTECTED]> wrote: > > > > On 4/19/07, Mikhail Fursov <[EMAIL PROTECTED]> wrote: > > > JET replies on SSE2 instructions and this patch does not fix it. The > > patch > > > fixes only OPT. > > > "client" mode contains JET as a first JIT, but I added code to JET to > > check > > > if SSE2 is available and refuse compilation if not. > > > The second JIT in 'client' mode is OPT and after JET is refused to > > compile a > > > method, OPT compiles it. > > > > > > I have another idea to check in JET if method contains double ops and > > > compile it if it does not. It will improve startup time and JVMTI > > support > > > significantly before JET is able to support 'doubles' on i586, because > > of > > > only small number of methods use doubles. > > > > Good idea. This above on 586/P3 can be phase I of P3 support. The rest > > is somewhat lower priority imho. Since the minimum it is being tested > > on is P3, why not call it P3? > > > The first name was p5. My first patch with cpuid integration use > 'p3' as the name. The only difference in the second patch is > 'p3' name changed to 'i586'. So we have a choice here :) > Actually I vote for the last > name. However I do not think the name is really matters here. Comments in > the file give detailed description for those who interested in details. > > -- > Mikhail Fursov >
-- Mikhail Fursov
