to more accurately describe what it does. Expand its doxygen comment
to describe what the backedge-taken count is and how it differs
from the actual iteration count of the loop. Adjust names and
comments in associated code accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@65382 91177308-0d34-0410-b5e6-96231b3b80d8
ashr instcombine to help expose this code. And apply the fix to
SelectionDAG's copy of this code too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@65364 91177308-0d34-0410-b5e6-96231b3b80d8
trip count value when the original loop iteration condition is
signed and the canonical induction variable won't undergo signed
overflow. This isn't required for correctness; it just preserves
more information about original loop iteration values.
Add a getTruncateOrSignExtend method to ScalarEvolution,
following getTruncateOrZeroExtend.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@64918 91177308-0d34-0410-b5e6-96231b3b80d8
modified in a way that may effect the trip count calculation. Change
IndVars to use this method when it rewrites pointer or floating-point
induction variables instead of using a doInitialization method to
sneak these changes in before ScalarEvolution has a chance to see
the loop. This eliminates the need for LoopPass to depend on
ScalarEvolution.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@64810 91177308-0d34-0410-b5e6-96231b3b80d8
it only reads memory! The other change has no
functional effect, it just seems more logical to
go in order of decreasing knowledge.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@64463 91177308-0d34-0410-b5e6-96231b3b80d8
Make sure the SCC pass manager initializes any contained
function pass managers. Without this, simplify-libcalls
would add nocapture attributes when run on its own, but
not when run as part of -std-compile-opts or similar.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@64443 91177308-0d34-0410-b5e6-96231b3b80d8
couldn't ever be the return of call instruction. However, it's quite possible
that said local allocation is itself the return of a function call. That's
what malloc and calloc are for, actually.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@64442 91177308-0d34-0410-b5e6-96231b3b80d8
loop induction on LP64 targets. When the induction variable is
used in addressing, IndVars now is usually able to inserst a
64-bit induction variable and eliminates the sign-extending cast.
This is also useful for code using C "short" types for
induction variables on targets with 32-bit addressing.
Inserting a wider induction variable is easy; the tricky part is
determining when trunc(sext(i)) expressions are no-ops. This
requires range analysis of the loop trip count. A common case is
when the original loop iteration starts at 0 and exits when the
induction variable is signed-less-than a fixed value; this case
is now handled.
This replaces IndVarSimplify's OptimizeCanonicalIVType. It was
doing the same optimization, but it was limited to loops with
constant trip counts, because it was running after the loop
rewrite, and the information about the original induction
variable is lost by that point.
Rename ScalarEvolution's executesAtLeastOnce to
isLoopGuardedByCond, generalize it to be able to test for
ICMP_NE conditions, and move it to be a public function so that
IndVars can use it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@64407 91177308-0d34-0410-b5e6-96231b3b80d8
function pass managers. Without this, simplify-libcalls
would add nocapture attributes when run on its own, but
not when run as part of -std-compile-opts or similar.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@64300 91177308-0d34-0410-b5e6-96231b3b80d8
they are useful to analyses other than BasicAliasAnalysis.cpp. Include
the full comment for isIdentifiedObject in the header file. Thanks to
Chris for suggeseting this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@63589 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@63400 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@63370 91177308-0d34-0410-b5e6-96231b3b80d8
DW_AT_APPLE_optimized flag is set when a compile_unit is optimized. The debugger takes advantage of this information some way.
DW_AT_APPLE_flags encodes command line options when certain env. variable is set. This is used by build engineers to track various gcc command lines used by by a project, irrespective of whether the project used makefile, Xcode or something else.
llvm-gcc patch is next.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@62888 91177308-0d34-0410-b5e6-96231b3b80d8
This avoids using a dangling pointer.
Reset NumSortedEntries after restoring Cache to avoid extraneous sorts.
This fixes the reduced sqlite3 testcase, but apparently not the whole app.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@62838 91177308-0d34-0410-b5e6-96231b3b80d8
analyses could be run without the caches properly sorted. This
can fix all sorts of weirdness. Many thanks to Bill for coming
up with the 'issorted' verification idea.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@62757 91177308-0d34-0410-b5e6-96231b3b80d8
doing very similar pointer capture analysis.
Factor out the common logic. The new version
is from FunctionAttrs since it does a better
job than the version in BasicAliasAnalysis
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@62461 91177308-0d34-0410-b5e6-96231b3b80d8
will get its preferred alignment. It has to be careful and cautiously assume
it will just get the ABI alignment. This prevents instcombine from rounding
up the alignment of a load/store without adjusting the alignment of the alloca.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61934 91177308-0d34-0410-b5e6-96231b3b80d8
