416 //
417 // When narrow oops can't fold into address expression (Sparc) and
418 // base is not null use decode_not_null and normal implicit null check.
419 // Note, decode_not_null node can be used here since it is referenced
420 // only on non null path but it requires special handling, see
421 // collect_null_checks():
422 //
423 // decode_not_null narrow_oop_reg, oop_reg // 'shift' and 'add base'
424 // [oop_reg + offset]
425 // NullCheck oop_reg
426 //
427 // With Zero base and when narrow oops can not fold into address
428 // expression use normal implicit null check since only shift
429 // is needed to decode narrow oop.
430 //
431 // decode narrow_oop_reg, oop_reg // only 'shift'
432 // [oop_reg + offset]
433 // NullCheck oop_reg
434 //
435 inline static bool gen_narrow_oop_implicit_null_checks() {
436 return Universe::narrow_oop_use_implicit_null_checks() &&
437 (narrow_oop_use_complex_address() ||
438 Universe::narrow_oop_base() != NULL);
439 }
440
441 // Is it better to copy float constants, or load them directly from memory?
442 // Intel can load a float constant from a direct address, requiring no
443 // extra registers. Most RISCs will have to materialize an address into a
444 // register first, so they may as well materialize the constant immediately.
445 static const bool rematerialize_float_constants;
446
447 // If CPU can load and store mis-aligned doubles directly then no fixup is
448 // needed. Else we split the double into 2 integer pieces and move it
449 // piece-by-piece. Only happens when passing doubles into C code or when
450 // calling i2c adapters as the Java calling convention forces doubles to be
451 // aligned.
452 static const bool misaligned_doubles_ok;
453
454 // Does the CPU require postalloc expand (see block.cpp for description of
455 // postalloc expand)?
|
416 //
417 // When narrow oops can't fold into address expression (Sparc) and
418 // base is not null use decode_not_null and normal implicit null check.
419 // Note, decode_not_null node can be used here since it is referenced
420 // only on non null path but it requires special handling, see
421 // collect_null_checks():
422 //
423 // decode_not_null narrow_oop_reg, oop_reg // 'shift' and 'add base'
424 // [oop_reg + offset]
425 // NullCheck oop_reg
426 //
427 // With Zero base and when narrow oops can not fold into address
428 // expression use normal implicit null check since only shift
429 // is needed to decode narrow oop.
430 //
431 // decode narrow_oop_reg, oop_reg // only 'shift'
432 // [oop_reg + offset]
433 // NullCheck oop_reg
434 //
435 inline static bool gen_narrow_oop_implicit_null_checks() {
436 // Advice matcher to perform null checks on the narrow oop side.
437 // Implicit checks are not possible on the uncompressed oop side anyway
438 // (at least not for read accesses).
439 // Performs significantly better (especially on Power 6).
440 if (!os::zero_page_read_protected()) {
441 return true;
442 }
443 return Universe::narrow_oop_use_implicit_null_checks() &&
444 (narrow_oop_use_complex_address() ||
445 Universe::narrow_oop_base() != NULL);
446 }
447
448 // Is it better to copy float constants, or load them directly from memory?
449 // Intel can load a float constant from a direct address, requiring no
450 // extra registers. Most RISCs will have to materialize an address into a
451 // register first, so they may as well materialize the constant immediately.
452 static const bool rematerialize_float_constants;
453
454 // If CPU can load and store mis-aligned doubles directly then no fixup is
455 // needed. Else we split the double into 2 integer pieces and move it
456 // piece-by-piece. Only happens when passing doubles into C code or when
457 // calling i2c adapters as the Java calling convention forces doubles to be
458 // aligned.
459 static const bool misaligned_doubles_ok;
460
461 // Does the CPU require postalloc expand (see block.cpp for description of
462 // postalloc expand)?
|