header. Getting it in the wrong order generated incorrect line markers in -E
mode. In the testcase from PR9861 we used to generate:
# 1 "test.c" 2
# 1 "./foobar.h" 1
# 0 "./foobar.h"
# 0 "./foobar.h" 3
# 2 "test.c" 2
now we properly produce:
# 1 "test.c" 2
# 1 "./foobar.h" 1
# 1 "./foobar.h" 3
# 2 "test.c" 2
This fixes PR9861.
llvm-svn: 131871
action the second time the event is removed (the first is the internal ->
external transition, the second when it is pulled off the public event
queue, and further times when it is put back because we are faking a
stop reason to hide the expression evaluation stops.
llvm-svn: 131869
result is non-zero. Implement an example optimization (PR9814), which allows us to
transform:
A / ((1 << B) >>u 2)
into:
A >>u (B-2)
which we compile into:
_divu3: ## @divu3
leal -2(%rsi), %ecx
shrl %cl, %edi
movl %edi, %eax
ret
instead of:
_divu3: ## @divu3
movb %sil, %cl
movl $1, %esi
shll %cl, %esi
shrl $2, %esi
movl %edi, %eax
xorl %edx, %edx
divl %esi, %eax
ret
llvm-svn: 131860
failing to form a memset, then having to delete it" but my approximation
isn't safe for self recurrent loops. Instead of doign a hack, just
do it the right way.
llvm-svn: 131858
I also changed -simplifycfg, -jump-threading and -codegenprepare to use this to produce slightly better code without any extra cleanup passes (AFAICT this was the only place in -simplifycfg where now-dead conditions of replaced terminators weren't being cleaned up). The only other user of this function is -sccp, but I didn't read that thoroughly enough to figure out whether it might be holding pointers to instructions that could be deleted by this.
llvm-svn: 131855
and set the address as an opcode address or as a callable address. This is
needed in various places in the thread plans to make sure that addresses that
might be found in symbols or runtime might already have extra bits set (ARM/Thumb).
The new functions are:
bool
Address::SetCallableLoadAddress (lldb::addr_t load_addr, Target *target);
bool
Address::SetOpcodeLoadAddress (lldb::addr_t load_addr, Target *target);
SetCallableLoadAddress will initialize a section offset address if it can,
and if so it might possibly set some bits in the address to make the address
callable (bit zero might get set for ARM for Thumb functions).
SetOpcodeLoadAddress will initialize a section offset address using the
specified target and it will strip any special address bits if needed
depending on the target.
Fixed the ABIMacOSX_arm::GetArgumentValues() function to require arguments
1-4 to be in the needed registers (previously this would incorrectly fallback
to the stack) and return false if unable to get the register values. The
function was also modified to first look for the generic argument registers
and then fall back to finding the registers by name.
Fixed the objective trampoline handler to use the new Address::SetOpcodeLoadAddress
function when needed to avoid address mismatches when trying to complete
steps into objective C methods. Make similar fixes inside the
AppleThreadPlanStepThroughObjCTrampoline::ShouldStop() function.
Modified ProcessGDBRemote::BuildDynamicRegisterInfo(...) to be able to deal with
the new generic argument registers.
Modified RNBRemote::HandlePacket_qRegisterInfo() to handle the new generic
argument registers on the debugserver side.
Modified DNBArchMachARM::NumSupportedHardwareBreakpoints() to be able to
detect how many hardware breakpoint registers there are using a darwin sysctl.
Did the same for hardware watchpoints in
DNBArchMachARM::NumSupportedHardwareWatchpoints().
llvm-svn: 131834
to determine outer template arguments lists for template
parameters. This is actually the problem behind PR9643, which I have
yet to figure out how to fix.
llvm-svn: 131822
Chris Lattner