llvm-svn: 63409

llvm-svn: 63408

llvm-svn: 63407

robust enough for general use.

llvm-svn: 63406

location.  We now -E a file containing "foo" into:

# 1 "t.c"
# 1 "t.c" 1
# 1 "<predefines>" 1
# 1 "t.c" 2
foo

instead of:

# 1 "t.c"
# 1 "t.c" 1
# 0 "t.c"
# 1 "<predefines>" 1
# 1 "t.c" 2
foo

llvm-svn: 63405

x86_64 ABI: Split small vectors which cross an eightbyte boundary. Down to 33/500 return type failures.

llvm-svn: 63404

llvm-svn: 63403

llvm-svn: 63402

 Each input file is encoded as a separate compile unit in LLVM debugging
information output. However, many target specific tool chains prefer to encode
only one compile unit in an object file. In this situation, the LLVM code
generator will include  debugging information entities in the compile unit 
that is marked as main compile unit. The code generator accepts maximum one main
compile unit per module. If a module does not contain any main compile unit 
then the code generator will emit multiple compile units in the output object 
file.

[Part 1]

Update DebugInfo APIs to accept optional boolean value while creating DICompileUnit  to mark the unit as "main" unit. By defaults all units are considered  non-main.  Update SourceLevelDebugging.html to document "main" compile unit.

Update DebugInfo APIs to not accept and encode separate source file/directory entries while creating various llvm.dbg.* entities. There was a recent, yet to be documented, change to include this additional information so no documentation changes are required here.

Update DwarfDebug to handle "main" compile unit. If "main" compile unit is seen then all DIEs are inserted into "main" compile unit. All other compile units are used to find source location for llvm.dbg.* values. If there is not any "main" compile unit then create unique compile unit DIEs for each llvm.dbg.compile_unit.

[Part 2]

Create separate llvm.dbg.compile_unit for each input file. Mark compile unit create for main_input_filename as "main" compile unit. Use appropriate compile unit, based on source location information collected from the tree node, while creating llvm.dbg.* values using DebugInfo APIs.

---

This is Part 1.

llvm-svn: 63400

llvm-svn: 63398

parameter that allows users to omit the printing of the source
location on a diagnostic. So basically it would omit the "abc.c:5:1: "
at the beginning of the line."

Patch by Alexei Svitkine!

llvm-svn: 63396

type" rather than the C definition. We do this because both C99 and
Clang always use "aggregate type" as "aggregate or union type", and
the C++ definition includes union types.

llvm-svn: 63395

llvm-svn: 63394

llvm-svn: 63393

llvm-svn: 63392

llvm-svn: 63391

llvm-svn: 63390

Thanks, Duncan.

llvm-svn: 63389

the LowerPartSet(). It didn't handle the situation correctly when
the low, high argument values are in reverse order (low > high)
with 'Val' type i32 (a corner case).

llvm-svn: 63388

llvm-svn: 63387

the LowerPartSet(). It didn't handle the situation correctly when 
the low, high argument values are in reverse order (low > high) 
with 'Val' type is i32 (a corner case).

llvm-svn: 63386

llvm-svn: 63385

is necessary for eventual gcc commmand line compatibility.

llvm-svn: 63384

 - This brings us down to an 8% failure rate on the first 500 return
   types tests (from 12%).

llvm-svn: 63383

llvm-svn: 63382

an illegal type.

llvm-svn: 63380

llvm-svn: 63379

llvm-svn: 63378

Enable emitting of constant values in non-default address space as well. The APIs emitting constants now take an additional parameter signifying the address space in which to emit. The APIs like getData8BitsDirective() etc are made virtual enabling targets to be able to define appropirate directivers for various sizes and address spaces.

llvm-svn: 63377

llvm-svn: 63376

llvm-svn: 63375

llvm-svn: 63374

llvm-svn: 63373

llvm-svn: 63372

llvm-svn: 63371

If a MachineInstr doesn't have a memoperand but has an opcode that
is known to load or store, assume its memory reference may alias
*anything*, including stack slots which the compiler completely
controls.

To partially compensate for this, teach the ScheduleDAG building
code to do basic getUnderlyingValue analysis. This greatly
reduces the number of instructions that require restrictive
dependencies. This code will need to be revisited when we start
doing real alias analysis, but it should suffice for now.

llvm-svn: 63370

llvm-svn: 63369

llvm-svn: 63368

llvm-svn: 63367

llvm-svn: 63366