- Apr 24, 2003
-
-
gerd authored
* src/compiler/ir1opt.lisp (recognize-known-call): Don't inline if *converting-for-interpreter*. This suppresses inlining when generating IR1 for interpretation because no type-checking IR1 is generated in this case, and the interpreter, internal-apply-loop for instance, doesn't do type checks is some other way either.
-
- Mar 04, 2001
-
-
pw authored
-
- Sep 26, 2000
-
-
dtc authored
are referenced, rather than also checking that none are set. Problems related to lambda-vars without a home may have been resolved now.
-
- Aug 09, 2000
-
-
dtc authored
propagation a chance before transforming to less amiable forms. A transform may now choose to be delayed by calling delay-transform giving a reason. The two supported reasons are :optimize to delay until IR1 optimization has completed, and :constraint to delay until after constraint propagation.
-
- Jul 07, 2000
-
-
dtc authored
return values, and replace them with function argument declarations which the compiler move carefully checks.
-
- Jul 06, 2000
-
-
dtc authored
causing problems: o Redefine coerce-to-values to convert a single value type into (values type), rather than the former definition (values type &rest t). A single value type such as fixnum is now equivalent to (values fixnum). Values-type-union and values-type-intersection will canonicalise values types with a single value such as (values fixnum) back to a single value type such as fixnum. o Now when the compiler makes assertions for the first value of continuations that may be generating multiple values it asserts the type as (values type &rest t), or as (value &optional type &rest t) if it is not sure that the continuation does generate a value. o Enhance the type check generation to better handle the now common values types with optional and rest arguments. Add the new function Values-types-asserted which converts asserted optional and rest arguments to required arguments that have been proven to be delivered, Thus an assertion such as (values &optional fixnum &rest t) will generate a fixnum type check if the proven type if (values t). o The compiler is now far more likely to pickup attempts to use an assertion to select a subset of values. For example (the (values fixnum) (values x y)) will generated a compiler warning. o Update single values type assertions where appropriate to clarify that the received values may be optional or that multiple values may be received. For example, a macro argument which had been asserted to be a list via (the list ,...) would now be asserted to be (the (values &optional list &rest t)) etc. o Have the IR1 translator for THE convert single value types into (values &optional type &rest t) so that code such as (the fixnum (values x y)) will still work acceptably. This does not restrict the possible type assertions as the values types may be used and are not modified.
-
dtc authored
value types, using the new support function values-types-defaulted.
-
dtc authored
incompatbile with the proven type of ARG, such as when ARG returns multiple values and CONT has a single value assertion. o After propagate-let-args, only delete the let when none of the variables are set, otherwise an unreferenced variable that is set can end up without a home which would be unexpected by later stages of the compiler. o Correct and enhance the values deftransform to adjust the node continuation asserted type which may otherwise be inconsistent with the new single value type, and set the node derived type to the received single-value-type.
-
- Feb 25, 1999
-
-
pw authored
It is a benign revision as no structures are redefined. At some later point the definitions in compiler/objdef could be removed, perhaps in sync with some other type change.
-
- Feb 24, 1998
-
-
dtc authored
non-flushable functions are flushed. For single value calls it had been just unlinking the result and inserting the constant but this failed to flush the call if it didn't have a flushable attribute, for example numeric constant coercions were not being flush when successful leading to rather inefficient code.
-
- Oct 31, 1994
-
-
ram authored
-
- Feb 11, 1994
-
-
cvs2git authored
-
- Jan 06, 1994
-
-
ram authored
optional-dispatch specified. The last fixed entry point won't be referenced by the XEP, so we can't count on that providing a T type input.
-
- Aug 31, 1993
-
-
ram authored
the function have no dest (and are going to be deleted.)
-
- Aug 19, 1993
-
-
wlott authored
from the dylan-function-var-function-info slot.
-
- May 12, 1993
-
-
ram authored
-
- May 11, 1993
-
-
ram authored
explicitly annotated as relevant.
-
- Mar 19, 1993
-
-
ram authored
don't choke on values types in the functional position.
-
- Mar 14, 1993
-
-
ram authored
from being inferred about function result types.
-
- Feb 03, 1993
-
-
ram authored
function type guarding the call (for example, calls to lambdas). In this case, we still want to call RECOGNIZE-KNOWN-CALL, since it will figure out what leaf we are referencing, and might also do something else interesting: inline expansion, etc.
-
- Jan 13, 1993
-
-
cvs2git authored
-
- Nov 03, 1992
-
-
ram authored
-
- Sep 24, 1992
-
-
ram authored
unreachable code notes.
-
- Sep 23, 1992
-
-
ram authored
local call converting.
-
- Sep 21, 1992
-
-
ram authored
-
- Sep 16, 1992
-
-
ram authored
-
- Sep 15, 1992
-
-
ram authored
-
- Sep 07, 1992
-
-
ram authored
better locality. Substantially revamped known call reoptimization so that more core is sharable with ir1-conversion. Formerly some stuff (like inline expansion) only happend at ir1-conversion time.
-
- Aug 04, 1992
-
-
ram authored
in RECOGNIZE-KNOWN-CALL, because it won't work. For now, SETF functions are never inline expanded.
-
- Jul 31, 1992
-
-
ram authored
source transform, even if there is no function-info.
-
- Jul 22, 1992
-
-
wlott authored
-
- Jun 04, 1992
-
-
ram authored
MAYBE-DELETE-EXIT to call MERGE-TAIL-SETS.
-
- Jun 03, 1992
-
-
ram authored
-
- Apr 14, 1992
-
-
ram authored
:NOTINLINE functional. The inlinep information must be retained, since we count on :NOTLININE calls never being local call converted.
-
- Apr 02, 1992
-
-
ram authored
continuation type assertions conflict.
-
- Apr 01, 1992
-
-
ram authored
-
- Feb 19, 1992
-
-
wlott authored
-
- Feb 11, 1992
-
-
ram authored
type, because there isn't any.
-
- Jan 25, 1992
-
-
ram authored
MV-combinations.
-
- Dec 20, 1991
-
-
ram authored
seems that we do derive inconsistent types in dead code.
-