llvm-6502/lib/Target
Chris Lattner 176f0416d1 some stuff is done
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@26004 91177308-0d34-0410-b5e6-96231b3b80d8
2006-02-05 07:54:37 +00:00
..
Alpha
CBackend
IA64
PowerPC
Skeleton
Sparc
SparcV8
SparcV9
X86
Makefile
MRegisterInfo.cpp
README.txt some stuff is done 2006-02-05 07:54:37 +00:00
SubtargetFeature.cpp
Target.td
TargetData.cpp
TargetFrameInfo.cpp
TargetInstrInfo.cpp
TargetMachine.cpp
TargetMachineRegistry.cpp
TargetSchedInfo.cpp
TargetSchedule.td
TargetSelectionDAG.td
TargetSubtarget.cpp

Target Independent Opportunities:

===-------------------------------------------------------------------------===

FreeBench/mason contains code like this:

static p_type m0u(p_type p) {
  int m[]={0, 8, 1, 2, 16, 5, 13, 7, 14, 9, 3, 4, 11, 12, 15, 10, 17, 6};
  p_type pu;
  pu.a = m[p.a];
  pu.b = m[p.b];
  pu.c = m[p.c];
  return pu;
}

We currently compile this into a memcpy from a static array into 'm', then
a bunch of loads from m.  It would be better to avoid the memcpy and just do
loads from the static array.

===-------------------------------------------------------------------------===

Get the C front-end to expand hypot(x,y) -> llvm.sqrt(x*x+y*y) when errno and
precision don't matter (ffastmath).  Misc/mandel will like this. :)

===-------------------------------------------------------------------------===

For all targets, not just X86:
When llvm.memcpy, llvm.memset, or llvm.memmove are lowered, they should be 
optimized to a few store instructions if the source is constant and the length
is smallish (< 8). This will greatly help some tests like Shootout/strcat.c
and fldry.

//===---------------------------------------------------------------------===//

Solve this DAG isel folding deficiency:

int X, Y;

void fn1(void)
{
  X = X | (Y << 3);
}

compiles to

fn1:
	movl Y, %eax
	shll $3, %eax
	orl X, %eax
	movl %eax, X
	ret

The problem is the store's chain operand is not the load X but rather
a TokenFactor of the load X and load Y, which prevents the folding.

There are two ways to fix this:

1. The dag combiner can start using alias analysis to realize that y/x
   don't alias, making the store to X not dependent on the load from Y.
2. The generated isel could be made smarter in the case it can't
   disambiguate the pointers.

Number 1 is the preferred solution.

//===---------------------------------------------------------------------===//

For dag combiner and instcombine:
int t(int X, int Y) { return 1 << (X+4); }  --> 16 << X

//===---------------------------------------------------------------------===//