start of a filename, not a filename+length.  All clients can produce a
null terminated name, and the system api's require null terminated 
strings anyway.

llvm-svn: 49041

llvm-svn: 49037

llvm-svn: 49036

llvm-svn: 49035

provides fast MappedFile::getFile for large files.

llvm-svn: 49034

1) stop using MappedFile.
2) if profitable use the sys::path::MapInFilePages api to
   read the file.
3) otherwise fallback to read.

When sys::path::MapInFilePages is implemented, this provides
several benefits:

#1: this avoids fragmenting memory for small files.
#2: this avoids extraneous stat calls when the file size is known.
#3: this only keeps the file descriptor open while reading the 
    file, not for the duration of the lifetime of the memory 
    buffer.  This fixes a serious clang FD 'leak' problem.

I believe that this will work on a win32 machine, but I don't have
one to test on.  I'd appreciate it if someone could check.

llvm-svn: 49031

llvm-svn: 49030

MemoryBuffer is higher level and more closely matches the model
needed.

llvm-svn: 49029

llvm-svn: 49027

llvm-svn: 49026

make getBase() return a const-correct pointer.

llvm-svn: 49025

not an mmapped file.  This more closely matches its requirements and
provides an implicitly null terminated buffer, something this
routine had to emulate itself before.

llvm-svn: 49024

and shared.  This complicates the design, is not used, and probably
doesn't even work.

llvm-svn: 49022

llvm-svn: 49020

llvm-svn: 49016

llvm-svn: 49014

llvm-svn: 49013

llvm-svn: 49012

llvm-svn: 49011

tons of out of date comments (really nothing throws here!) and fixes
some other fairly glaring issues: "size" used to return the size of 
the file *and* change it, depending on how you called it.

llvm-svn: 49009

llvm-svn: 49008

not marked nounwind, or for all functions when -enable-eh
is set, provided the target supports Dwarf EH.

llvm-gcc generates nounwind in the right places; other FEs
will need to do so also.  Given such a FE, -enable-eh should
no longer be needed.

llvm-svn: 49006

llvm-svn: 49002

crash miscompilations.

llvm-svn: 49000

not the end.

llvm-svn: 48999

llvm-svn: 48995

llvm-svn: 48994

llvm-svn: 48982

llvm-svn: 48977

The support for remat of instructions with a register operand is hackish, to say the least. Since the register operand guaranteed to be PIC base and that it is already live at all uses, we are making sure it will not be spilled after its uses are rematerialized for both performance and correctness reasons.

llvm-svn: 48976

llvm-svn: 48973

llvm-svn: 48971

llvm-svn: 48967

llvm-svn: 48965

patch by David Chisnall.

llvm-svn: 48963

llvm-svn: 48961

llvm-svn: 48947

when something changes, instead of moving forward.  This allows us to 
simplify memset lowering, inserting the memset at the end of the range of 
stuff we're touching instead of at the start.

This, in turn, allows us to make use of the addressing instructions already
used in the function instead of inserting our own.  For example, we now
codegen:

	%tmp41 = getelementptr [8 x i8]* %ref_idx, i32 0, i32 0		; <i8*> [#uses=2]
	call void @llvm.memset.i64( i8* %tmp41, i8 -1, i64 8, i32 1 )

instead of:

	%tmp20 = getelementptr [8 x i8]* %ref_idx, i32 0, i32 7		; <i8*> [#uses=1]
	%ptroffset = getelementptr i8* %tmp20, i64 -7		; <i8*> [#uses=1]
	call void @llvm.memset.i64( i8* %ptroffset, i8 -1, i64 8, i32 1 )

llvm-svn: 48940

into a memset!) faster by avoiding an allocation of an std::list node.

llvm-svn: 48939

llvm-svn: 48937