target directories themselves. This also means that VMCore no longer
needs to know about every target's list of intrinsics. Future work
will include converting the PowerPC target to this interface as an
example implementation.
llvm-svn: 63765
s/ParamAttr/Attribute/g
s/PAList/AttrList/g
s/FnAttributeWithIndex/AttributeWithIndex/g
s/FnAttr/Attribute/g
This sets the stage
- to implement function notes as function attributes and
- to distinguish between function attributes and return value attributes.
This requires corresponding changes in llvm-gcc and clang.
llvm-svn: 56622
1. There is now a "PAListPtr" class, which is a smart pointer around
the underlying uniqued parameter attribute list object, and manages
its refcount. It is now impossible to mess up the refcount.
2. PAListPtr is now the main interface to the underlying object, and
the underlying object is now completely opaque.
3. Implementation details like SmallVector and FoldingSet are now no
longer part of the interface.
4. You can create a PAListPtr with an arbitrary sequence of
ParamAttrsWithIndex's, no need to make a SmallVector of a specific
size (you can just use an array or scalar or vector if you wish).
5. All the client code that had to check for a null pointer before
dereferencing the pointer is simplified to just access the
PAListPtr directly.
6. The interfaces for adding attrs to a list and removing them is a
bit simpler.
Phase #2 will rename some stuff (e.g. PAListPtr) and do other less
invasive changes.
llvm-svn: 48289
throw exceptions", just mark intrinsics with the nounwind
attribute. Likewise, mark intrinsics as readnone/readonly
and get rid of special aliasing logic (which didn't use
anything more than this anyway).
llvm-svn: 44544
Change the interface to the getName, getType, getDeclaration methods to
include the "actual" types of the result/arguments. This is necessary to
support overloaded intrinsics.
llvm-svn: 35542
This patch is an incremental step towards supporting a flat symbol table.
It de-overloads the intrinsic functions by providing type-specific intrinsics
and arranging for automatically upgrading from the old overloaded name to
the new non-overloaded name. Specifically:
llvm.isunordered -> llvm.isunordered.f32, llvm.isunordered.f64
llvm.sqrt -> llvm.sqrt.f32, llvm.sqrt.f64
llvm.ctpop -> llvm.ctpop.i8, llvm.ctpop.i16, llvm.ctpop.i32, llvm.ctpop.i64
llvm.ctlz -> llvm.ctlz.i8, llvm.ctlz.i16, llvm.ctlz.i32, llvm.ctlz.i64
llvm.cttz -> llvm.cttz.i8, llvm.cttz.i16, llvm.cttz.i32, llvm.cttz.i64
New code should not use the overloaded intrinsic names. Warnings will be
emitted if they are used.
llvm-svn: 25366
this and have it in about the same form, I think this makes sense.
on X86, you do a RDTSC (64bit result, from any ring since the P5MMX)
on Alpha, you do a RDCC
on PPC, there is a sequence which may or may not work depending on how things
are setup by the OS. Or something like that. Maybe someone who knows PPC
can add support. Something about the time base register.
on Sparc, you read %tick, which in some solaris versions (>=8) is readable by
userspace
on IA64 read ar.itc
So I think the ulong is justified since all of those are 64bit.
Support is slighly flaky on old chips (P5 and lower) and sometimes
depends on OS (PPC, Sparc). But for modern OS/Hardware (aka this decade),
we should be ok.
I am still not sure what to do about lowering. I can either see a lower to 0, to
gettimeofday (or the target os equivalent), or loudly complaining and refusing to
continue.
I am commiting an Alpha implementation. I will add the X86 implementation if I
have to (I have use of it in the near future), but if someone who knows that
backend (and the funky multi-register results) better wants to add it, it would
take them a lot less time ;)
TODO: better lowering and legalizing, and support more platforms
llvm-svn: 24299
population (ctpop). Generic lowering is implemented, however only promotion
is implemented for SelectionDAG at the moment.
More coming soon.
llvm-svn: 21676
