search for: gundapaneni

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Mehdi > Amini via llvm-dev > Sent: Friday, January 06, 2017 11:10 AM > To: Sumanth Gundapaneni > Cc: LLVM Developers > Subject: Re: [llvm-dev] LLVMTargetMachine with optimization level passed > from clang. > > > > On Jan 6, 2017, at 10:56 AM, Sumanth Gundapaneni > <sgundapa at codeaurora.org> wrote: > > > > Here is a problem scenario. > > &gt...

...efault) addPass(&xxxxx); This pass will be run at -O1 too since clang is creating the TargetMachine with CodeGenOpt::Default for -O1. --Sumanth G -----Original Message----- From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Friday, January 6, 2017 12:37 PM To: Sumanth Gundapaneni <sgundapa at codeaurora.org> Cc: jpaquette at apple.com; LLVM Developers <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] LLVMTargetMachine with optimization level passed from clang. > On Jan 6, 2017, at 7:59 AM, Sumanth Gundapaneni via llvm-dev <llvm-dev at lists.llvm.org&g...

...get=<triple>” as CMAKE_C_FLAGS :) With out –gcc-toolchain, clang cannot find the linker and picks the system linker which is usually /usr/bin/ld on a linux system. --Sumanth G From: C Bergström [mailto:cbergstrom at pathscale.com] Sent: Tuesday, January 27, 2015 11:51 AM To: Sumanth Gundapaneni Cc: llvmdev at cs.uiuc.edu; Rafael Ávila de Espíndola; Takumi NAKAMURA Subject: Re: [LLVMdev] CMake: Gold linker detection On Wed, Jan 28, 2015 at 2:27 AM, Sumanth Gundapaneni <sgundapa at codeaurora.org <mailto:sgundapa at codeaurora.org> > wrote: Hi Rafael,...

Hi, AFAIK, the tools "symbolizer, objdump and nm" need a demangler. I see there is libcxxabi which provides the demangle library. But there is no support to build libcxxabi on windows with MSVC. This left a huge void and my symbolizer cannot work on Windows if built with MSVC. Instead of mucking around OS dependencies, why shouldn't we have a demangle library in LLVM.

...lvm-dev at lists.llvm.org> wrote: > > I want the optimization to be turned on at -O1 and above. > In my case, it is a target independent back-end pass. (Eg: > MachinePipeliner) > > > On 2017-01-04 18:10, Mehdi Amini wrote: >>> On Jan 4, 2017, at 4:03 PM, Sumanth Gundapaneni via llvm-dev >>> <llvm-dev at lists.llvm.org> wrote: >>> I see the BackendUtil.cpp of Clang creates the TargetMachine with >>> the optimization level based on below mentioned logic >>> CodeGenOpt::Level OptLevel = CodeGenOpt::Default; switch >>&gt...

On 28 July 2015 at 17:52, Sumanth Gundapaneni <sgundapa at codeaurora.org> wrote: > Android bionic libc doesn’t provide a __modsi3, instead it provides > “__aeabi_idivmod”. Hi Sumanth, Have a look at ARMSubtarget.h, functions: bool isTargetAEABI() They control the lowering of DIV/MOD calls in ARMISelLowering.cpp. Maybe Androi...

Hi, I see there is an inconsistency in LLVM libc calls. For a modulo (reminder) operation, clang -target arm-none-linux-gnueabi generates "__modsi3". clang -target arm-none-eabi generates "__aeabi_idivmod" clang -target arm-linux-androideabi generates "__modsi3" Android bionic libc doesn't provide a __modsi3, instead it provides

Hi, I am observing a deadlock with llvm-lit on windows 7. When I attached a debugger, the communicate() call is blocked. In file utils/lit/lit/TestRunner.py > # FIXME: There is probably still deadlock potential here. Yawn. > procData = [None] * len(procs) > procData[-1] = procs[-1].communicate() I am invoking python directly on windows to run the unit tests.

...64 and works for both LLVM and GCC ? If the compiler-rt build works for others, I would like to see their cmake recipe ? --Sumanth G -----Original Message----- From: Tim Northover [mailto:t.p.northover at gmail.com] Sent: Wednesday, December 10, 2014 8:02 AM To: Christophe Lyon Cc: Renato Golin; Gundapaneni, Sumanth; llvmdev at cs.uiuc.edu; Kostya Serebryany Subject: Re: [Compiler-rt] -march=aarch64 flag in gcc/clang > Not sure what r181130 is supposed to do, though, since it introduces a > buggy option. I didn't even have compiler-rt checked out when I was doing that; I was just trying t...

On 16 December 2014 at 21:12, Gundapaneni, Sumanth <sgundapa at quicinc.com> wrote: > The point here is, if you are not building for Android. > You will hit this patch with cmake configuration -DCOMPILER_RT_TEST_TRIPLE=aarch64-linux-gnu > > + elseif("${COMPILER_RT_TEST_TARGET_ARCH}" MATCHES "aarch64")...

I see the BackendUtil.cpp of Clang creates the TargetMachine with the optimization level based on below mentioned logic CodeGenOpt::Level OptLevel = CodeGenOpt::Default; switch (CodeGenOpts.OptimizationLevel) { default: break; case 0: OptLevel = CodeGenOpt::None; break; case 3: OptLevel = CodeGenOpt::Aggressive; break; } As per my understanding, the correspondence between

Hi Rafael, I looked at the code which you pushed a while ago to check for the gold linker. Code below: execute_process( COMMAND ${CMAKE_C_COMPILER} -Wl,--version OUTPUT_VARIABLE stdout ERROR_QUIET) if("${stdout}" MATCHES "GNU gold") set(LLVM_LINKER_IS_GOLD ON) endif() I was trying to build runtime libraries (compiler-rt)

...out your CPU's features, either locally or upstream. 4. Pass "-mhwdiv=arm,thumb" to Clang (or less if you only have hwdiv in one mode). --Sumanth G -----Original Message----- From: Tim Northover [mailto:t.p.northover at gmail.com] Sent: Tuesday, January 27, 2015 6:44 PM To: Sumanth Gundapaneni Cc: LLVM Developers Mailing List; Roman Divacky; Ana Pazos Subject: Re: [LLVMdev] CPUStringIsValid() into MCSubtargetInfo and use it for ARM .cpu parsing Hi Sumanth, > Shouldn’t the eabi attributes be honored ? EABI attributes are instructions for the linker on which object files are compatib...

I want the optimization to be turned on at -O1 and above. In my case, it is a target independent back-end pass. (Eg: MachinePipeliner) On 2017-01-04 18:10, Mehdi Amini wrote: >> On Jan 4, 2017, at 4:03 PM, Sumanth Gundapaneni via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> >> I see the BackendUtil.cpp of Clang creates the TargetMachine with >> the optimization level based on below mentioned logic >> >> CodeGenOpt::Level OptLevel = CodeGenOpt::Default; >> switch (C...

Hi, I wonder if this is a valid flag in either clang/gcc. The flag in question is "-march=aarch64". I verified with latest tip and neither clang nor gcc fail to recognize this flag. This piece of code is in cmake/config-ix.cmake in compiler-rt repo. + elseif("${COMPILER_RT_TEST_TARGET_ARCH}" MATCHES "aarch64") + test_target_arch(aarch64

Hi, I am planning to add support to CMake so that the binaries of llvm will have a prefix appended to it. At this point, I am stuck on which approach to follow 1. Append the prefix during build and install time. If so, this might involve tweaking lit infrastructure to make sure lit picks the prefixed binaries. 2. Append the prefix only during install time. a. Either

Hi Hans, I have attached a unit test which demonstrates a hang/infinite loop with the opt built with release_36 sources. The fixes are already pushed to "master" branch. The revisions r226588 and r226616 should be pushed to release_36 to fix the unit test. --Sumanth G -------------- next part -------------- An HTML attachment was scrubbed... URL:

I have legit requirement to keep the switch generated lookup table in function section. The lookup table is being generated in SimplifyCFG pass and is treated as a global. Is there a good way to mark these lookup tables and recognize them later to keep them in function sections. --Sumanth -------------- next part -------------- An HTML attachment was scrubbed... URL:

...M community is doing, > ie. building all in one tree. > I should also mention that the doc at http://clang.llvm.org/get_started.html should be updated since it seems that configure is deprecated in favor of cmake. Christophe. > cheers, > --renato > > On 1 December 2014 at 22:42, Gundapaneni, Sumanth <sgundapa at quicinc.com> wrote: >> Hi, >> >> I wonder if this is a valid flag in either clang/gcc. >> >> The flag in question is “-march=aarch64”. I verified with latest tip and >> neither clang nor gcc fail to recognize this flag. >>...

Hi, What is the guarantee that the codegen is same across Release and Release+Asserts build (except the known differences)? I assume there is no guarantee and it is possible to drop a bug like this. Personally I feel it is very expensive to debug and it depends on each scenario. Most of the bots test the Release+Asserts mode and any thoughts on how we can catch this sort of a problem