llvm-svn: 11896

that they are as far away from the loads as possible.

llvm-svn: 11895

MRegisterInfo::isPhysicalRegister().

llvm-svn: 11894

llvm-svn: 11892

llvm-svn: 11891

llvm-svn: 11890

llvm-svn: 11889

Made removing the object files a separate sh command so that it can easily
be commented out.

llvm-svn: 11888

llvm-svn: 11887

Oops.

llvm-svn: 11886

2004-02-26-FPNotPrintableConstants.llx ensures that constants used in an
LLVM program are declared static if they are assigned to global variables.
2004-02-26-LinkOnceFunctions.llx ensures that linkonce functions get the
weak attribute.

llvm-svn: 11885

Functions with linkonce linkage are declared with weak linkage.
Global floating point constants used to represent unprintable values
(such as NaN and infinity) are declared static so that they don't interfere
with other CBE generated translation units.

llvm-svn: 11884

are beastly ConstantPointerRefs in the way...

llvm-svn: 11883

MRegisterInfo::is{Physical,Virtual}Register. Apply appropriate fixes
to relevant files.

llvm-svn: 11882

llvm-svn: 11881

multiple type names for the same structural type.  Make DTE eliminate all
but one of the type names

llvm-svn: 11879

all dynamically allocated LLVM values 4 bytes smaller, eliminate some vtables, and
make Value's destructor faster.

This makes Function derive from Annotation now because it is the only core LLVM
class that still has an annotation stuck onto it: MachineFunction.
MachineFunction is obviously horrible and gross (like most other annotations), but
will be the subject of refactorings later in the future.  Besides many fewer
Function objects are dynamically allocated that instructions blocks, constants,
types, etc... :)

llvm-svn: 11878

llvm-svn: 11876

llvm-svn: 11875

llvm-svn: 11874

llvm-svn: 11873

llvm-svn: 11872

having the compiler emit RTTI and vtables to EVERY translation unit.

llvm-svn: 11871

   if (X == 0 || X == 2)

...where the comparisons and branches are in different blocks... into a switch
instruction.  This comes up a lot in various programs, and works well with
the switch/switch merging code I checked earlier.  For example, this testcase:

int switchtest(int C) {
  return C == 0 ? f(123) :
         C == 1 ? f(3123) :
         C == 4 ? f(312) :
         C == 5 ? f(1234): f(444);
}

is converted into this:
        switch int %C, label %cond_false.3 [
                 int 0, label %cond_true.0
                 int 1, label %cond_true.1
                 int 4, label %cond_true.2
                 int 5, label %cond_true.3
        ]

instead of a whole bunch of conditional branches.

Admittedly the code is ugly, and incomplete.  To be complete, we need to add
br -> switch merging and switch -> br merging.  For example, this testcase:

struct foo { int Q, R, Z; };
#define A (X->Q+X->R * 123)
int test(struct foo *X) {
  return A  == 123 ? X1() :
        A == 12321 ? X2():
        (A == 111 || A == 222) ? X3() :
        A == 875 ? X4() : X5();
}

Gets compiled to this:
        switch int %tmp.7, label %cond_false.2 [
                 int 123, label %cond_true.0
                 int 12321, label %cond_true.1
                 int 111, label %cond_true.2
                 int 222, label %cond_true.2
        ]
...
cond_false.2:           ; preds = %entry
        %tmp.52 = seteq int %tmp.7, 875         ; <bool> [#uses=1]
        br bool %tmp.52, label %cond_true.3, label %cond_false.3

where the branch could be folded into the switch.

This kind of thing occurs *ALL OF THE TIME*, especially in programs like
176.gcc, which is a horrible mess of code.  It contains stuff like *shudder*:

#define SWITCH_TAKES_ARG(CHAR) \
  (   (CHAR) == 'D' \
   || (CHAR) == 'U' \
   || (CHAR) == 'o' \
   || (CHAR) == 'e' \
   || (CHAR) == 'u' \
   || (CHAR) == 'I' \
   || (CHAR) == 'm' \
   || (CHAR) == 'L' \
   || (CHAR) == 'A' \
   || (CHAR) == 'h' \
   || (CHAR) == 'z')

and

#define CONST_OK_FOR_LETTER_P(VALUE, C)                 \
  ((C) == 'I' ? SMALL_INTVAL (VALUE)                    \
   : (C) == 'J' ? SMALL_INTVAL (-(VALUE))               \
   : (C) == 'K' ? (unsigned)(VALUE) < 32                \
   : (C) == 'L' ? ((VALUE) & 0xffff) == 0               \
   : (C) == 'M' ? integer_ok_for_set (VALUE)            \
   : (C) == 'N' ? (VALUE) < 0                           \
   : (C) == 'O' ? (VALUE) == 0                          \
   : (C) == 'P' ? (VALUE) >= 0                          \
   : 0)

and

#define LEGITIMIZE_ADDRESS(X,OLDX,MODE,WIN)                     \
{                                                               \
  if (GET_CODE (X) == PLUS && CONSTANT_ADDRESS_P (XEXP (X, 1))) \
    (X) = gen_rtx (PLUS, SImode, XEXP (X, 0),                   \
                   copy_to_mode_reg (SImode, XEXP (X, 1)));     \
  if (GET_CODE (X) == PLUS && CONSTANT_ADDRESS_P (XEXP (X, 0))) \
    (X) = gen_rtx (PLUS, SImode, XEXP (X, 1),                   \
                   copy_to_mode_reg (SImode, XEXP (X, 0)));     \
  if (GET_CODE (X) == PLUS && GET_CODE (XEXP (X, 0)) == MULT)   \
    (X) = gen_rtx (PLUS, SImode, XEXP (X, 1),                   \
                   force_operand (XEXP (X, 0), 0));             \
  if (GET_CODE (X) == PLUS && GET_CODE (XEXP (X, 1)) == MULT)   \
    (X) = gen_rtx (PLUS, SImode, XEXP (X, 0),                   \
                   force_operand (XEXP (X, 1), 0));             \
  if (GET_CODE (X) == PLUS && GET_CODE (XEXP (X, 0)) == PLUS)   \
    (X) = gen_rtx (PLUS, Pmode, force_operand (XEXP (X, 0), NULL_RTX),\
                   XEXP (X, 1));                                \
  if (GET_CODE (X) == PLUS && GET_CODE (XEXP (X, 1)) == PLUS)   \
    (X) = gen_rtx (PLUS, Pmode, XEXP (X, 0),                    \
                   force_operand (XEXP (X, 1), NULL_RTX));      \
  if (GET_CODE (X) == SYMBOL_REF || GET_CODE (X) == CONST       \
           || GET_CODE (X) == LABEL_REF)                        \
    (X) = legitimize_address (flag_pic, X, 0, 0);               \
  if (memory_address_p (MODE, X))                               \
    goto WIN; }

and others.  These macros get used multiple times of course.  These are such
lovely candidates for macros, aren't they?  :)

This code also nicely handles LLVM constructs that look like this:

  if (isa<CastInst>(I))
   ...
  else if (isa<BranchInst>(I))
   ...
  else if (isa<SetCondInst>(I))
   ...
  else if (isa<UnwindInst>(I))
   ...
  else if (isa<VAArgInst>(I))
   ...

where the isa can obviously be a dyn_cast as well.  Switch instructions are a
good thing.

llvm-svn: 11870

llvm-svn: 11868

other clients.  The problem is that the nullVal member was left to the default
constructor to initialize, which for int's does nothing (ie, leaves it unspecified).

To get a zero value, we must use T().  It's C++ wonderful? :)

llvm-svn: 11867

Remove .micro references as those files no longer exist and add some more recent Makefile additions to the list

llvm-svn: 11866

llvm-svn: 11865

llvm-svn: 11864

not have any globals.

llvm-svn: 11863

llvm-svn: 11862

removes some cruft from 255.vortex, cleaning up after DAE and IPCP, which
do horrible, beautiful, things to vortex.

llvm-svn: 11861

bugs.  Thanks Brian!

llvm-svn: 11859

llvm-svn: 11858

llvm-svn: 11857

them when all the problem areas are fixed.

llvm-svn: 11855

llvm-svn: 11854

llvm-svn: 11853

 1. Functions do not make things incomplete, only variables
 2. Constant global variables no longer need to be marked incomplete, because
    we are guaranteed that the initializer for the global will be in the
    graph we are hacking on now.  This makes resolution of indirect calls happen
    a lot more in the bu pass, supports things like vtables and the C counterparts
    (giant constant arrays of function pointers), etc...

Testcase here: test/Regression/Analysis/DSGraph/constant_globals.ll

llvm-svn: 11852

llvm-svn: 11851