- Add a AnalyzeCallResult specialized for calls which produce a single value. This is used by fastisel.

llvm-svn: 55879

llvm-svn: 55878

llvm-svn: 55877

llvm-svn: 55876

def : Pat<(i8 (trunc GR32:$src)),
          (i8 (EXTRACT_SUBREG (MOV32to32_ GR32:$src), x86_subreg_8bit))>

llvm-svn: 55875

this pass doesnt seem to be used, but still it's now a little more correct

llvm-svn: 55873

call (thus changing the call site) it didn't
inform the callgraph about this.  But the
call site does matter - as shown by the testcase,
the callgraph become invalid after the inliner
ran (with an edge between two functions simply
missing), resulting in wrong deductions by
GlobalsModRef.

llvm-svn: 55872

someone with llvm-gcc installed please test if the Codegen/function-attributes.c test isn't skip in your system. thanks.

llvm-svn: 55871

a many-to-one relationship between TagDecl's and types.

llvm-svn: 55870

If you're on some other platform, the correct definition for this macro 
would be appreciated; to find the correct definition, just run the 
following command:

echo | gcc -dM -E - | grep USER_LABEL_PREFIX

llvm-svn: 55869

llvm-svn: 55868

llvm-svn: 55867

llvm-svn: 55866

llvm-svn: 55865

i32>.  This is a little messy, but it works.

We should really get rid of the intrinsics, though, since they map
perfectly well to standard LLVM instructions.

llvm-svn: 55864

out of ScheduleDAGEmit.cpp and into SelectionDAGISel.cpp. This
allows it to be run exactly once per function, even if multiple
SelectionDAG iterations happen in the entry block, as may happen
with FastISel.

llvm-svn: 55863

llvm-svn: 55862

llvm-svn: 55861

that they read the rounding mode.  This is conservatively
correct, which they weren't before.  We can do more
optimization on these if we actually model the rounding
mode.

llvm-svn: 55860

because it does not maintain a correct list
of callsites.  I discovered (see following
commit) that the inliner will create a wrong
callgraph if it is fed a callgraph with
correct edges but incorrect callsites.  These
were created by Prune-EH, and while it wasn't
done via removeCallEdgeTo, it could have been
done via removeCallEdgeTo, which is an accident
waiting to happen.  Use removeCallEdgeFor
instead.

llvm-svn: 55859

readonly.

llvm-svn: 55858

llvm-svn: 55857

llvm-svn: 55856

llvm-svn: 55855

llvm-svn: 55854

llvm-svn: 55853

llvm-svn: 55849

llvm-svn: 55846

llvm-svn: 55845

llvm-svn: 55844

llvm-svn: 55843

approach here.

llvm-svn: 55842

Add comment back that Argiris pointed out that I mistakenly removed (the comments below it were stale, so I accidently removed the whole thing).

llvm-svn: 55841

llvm-svn: 55840

Change struct forward declarations and definitions to use unique RecordDecls, as opposed to creating a single RecordDecl and reusing it.

This change effects both RecordDecls and CXXRecordDecls, but does not effect EnumDecls (yet).

The motivation of this patch is as follows:
- Capture more source information, necessary for refactoring/rewriting clients.

- Pave the way to resolve ownership issues with RecordDecls with the forthcoming
  addition of DeclGroups.

Current caveats:
- Until DeclGroups are in place, we will leak RecordDecls not explicitly
  referenced by the AST.  For example:

    typedef struct { ... } x;  

  The RecordDecl for the struct will be leaked because the TypedefDecl doesn't
  refer to it.  This will be solved with DeclGroups.
  
- This patch also (temporarily) breaks CodeGen.  More below.

High-level changes:
- As before, TagType still refers to a TagDecl, but it doesn't own it.  When
  a struct/union/class is first referenced, a RecordType and RecordDecl are
  created for it, and the RecordType refers to that RecordDecl.  Later, if
  a new RecordDecl is created, the pointer to a RecordDecl in RecordType is
  updated to point to the RecordDecl that defines the struct/union/class.

- TagDecl and RecordDecl now how a method 'getDefinition()' to return the
  TagDecl*/RecordDecl* that refers to the TagDecl* that defines a particular
  enum/struct/class/union. This is useful from going from a RecordDecl* that
  defines a forward declaration to the RecordDecl* that provides the actual
  definition. Note that this also works for EnumDecls, except that in this case
  there is no distinction between forward declarations and definitions (yet).

- Clients should no longer assume that 'isDefinition()' returns true from a
  RecordDecl if the corresponding struct/union/class has been defined.
  isDefinition() only returns true if a particular RecordDecl is the defining
  Decl. Use 'getDefinition()' instead to determine if a struct has been defined.

- The main changes to Sema happen in ActOnTag. To make the changes more
  incremental, I split off the processing of enums and structs et al into two
  code paths. Enums use the original code path (which is in ActOnTag) and
  structs use the ActOnTagStruct. Eventually the two code paths will be merged,
  but the idea was to preserve the original logic both for comparison and not to
  change the logic for both enums and structs all at once.

- There is NO CHAINING of RecordDecls for the same RecordType. All RecordDecls
  that correspond to the same type simply have a pointer to that type. If we
  need to figure out what are all the RecordDecls for a given type we can build
  a backmap.

- The diff in CXXRecordDecl.[cpp,h] is actually very small; it just mimics the
  changes to RecordDecl. For some reason 'svn' marks the entire file as changed.

Why is CodeGen broken:
- Codegen assumes that there is an equivalence between RecordDecl* and
  RecordType*. This was true before because we only created one RecordDecl* for
  a given RecordType*, but it is no longer true. I believe this shouldn't be too
  hard to change, but the patch was big enough as it is.
  
I have tested this patch on both the clang test suite, and by running the static analyzer over Postgresql and a large Apple-internal project (mix of Objective-C and C).  

llvm-svn: 55839

llvm-svn: 55838

edges one by one by hand.

llvm-svn: 55836

llvm-svn: 55835

llvm-svn: 55834

llvm-svn: 55833