similar to: Get the address of ConstantDataArray

Thanks Tim, I'll try to solve my problem ASAP, if I cannot maybe I'll some other clarifications. Thanks again On Sat, Mar 9, 2019, 06:03 Tim Northover <t.p.northover at gmail.com> wrote: > Hi Alberto, > > On Sat, 9 Mar 2019 at 05:50, Alberto Barbaro via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > i8* getelementptr inbounds ([7 x i8], [7 x i8]*

Hello, I have some questions regarding folding operations with symbols during the instruction print stage with MC. At the moment I'm working with global symbols but i guess that other symbol types should be equivalent. My first question is how can i negate the address of a symbol? Consider this piece of code: char g_var[80]; char foo(int a) { return g_var[a]; } this gets compiles into

For background on these calls, see <http://lists.llvm.org/pipermail/llvm-dev/2019-September/135087.html>. Reminder: the purpose is to co-ordinate between active contributors. If you have support questions etc then it's best to post to llvm-dev. We have a call every alternate Thursday at 4pm BST, via <https://meet.google.com/ske-zcog-spp>. We have created a shared calendar which

Hey llvm-dev, What's the best method to test performance of Clang generated executables? Are the nightly tests in test-suite sufficient? I'm looking for publicly available tests/suites with a good breadth of coverage... Thanks, Cam -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Devs, since risc-v has a register $tp which is thread pointer. is it possible to have __builtin_thread_pointer for RISC-V? I am not sure what could be corresponding instructions? ./kamlesh

Hi all, I am trying to implement statepoints for the AArch64 target and I’m running into the issue where the following bitcode: define i32 addrspace(1)* @test(i32 addrspace(1)* %ptr) gc "statepoint-example" { entry: call token (i64, i32, i1 ()*, i32, i32, ...) @llvm.experimental.gc.statepoint.p0f_i1f(i64 0, i32 0, i1 ()* @foo, i32 0, i32 0, i32 0, i32 0, i32 addrspace(1)* %ptr) ret

Hi all developers, I'm changing compiler from gcc to llvm on a RISCV target now. but I found in some case the assembly code generated by llvm is much more than gcc. It cause my program's performance about 40% decrease. The flowing is a simple test code. It shows the problem. We can see than gcc prefer to use pointer to iterate the array, but llvm perfere to use index to iterate

This approximately follows my understanding and expectation. I think that, if you have commit access, commits to improve release notes fall under the contribution guidelines for documentation and therefore do not require a full Phabricator review. I know Alex Bradbury tries to coordinate the RISC-V backend-related release notes based on the backend changes since the last release, and this seems

Hi, Sam. I think that it's a fair comparison. Keep in mind that the GP is only used to reach global variables of local scope and the GOT, where the address of global variables of global scope reside. This model assumes that the distance between the GP and the global data area, GOT and local scope variables is defined at link time. __ Evandro Menezes ◊ SiFive ◊ Austin, TX > On Mar

Thanks. I have checked the hook DAGCombiner::isMulAddWithConstProfitable And I think the above condition is too aggressive. // If the add only has one use, this would be OK to do. if (AddNode.getNode()->hasOneUse()) return true; Shall we make it to if (AddNode.getNode()->hasOneUse() && TargetLowering.isCheaperCommuteAddMul(......)) return true; The virtual hook

Oh, I wasn’t really thinking about devices without an MMU where the addresses are physically separated. Makes sense. This reminds me of rwpi on ARM; it has a sort of similar scheme of referring to data indirectly through a pointer, but it also changes the ABI to keep the pointer in a reserved register. -Eli From: Evandro Menezes <evandro.menezes at sifive.com> Sent: Friday, March 20, 2020

There are 1500 tests total, and about 100 on the platform-agnostic blacklist. Alex and I do not think this is an onerous burden for maintenance, either as an external test suite or if the test suite is imported. In the long term, if we import the tests, we know we will have to do updates when the Embecosm work lands, and beyond that updates can be more sporadic. It’s not clear to me how much

Hi, I'm having a hard time finding an answer to what I assume is a very basic idea. I'm trying to produce this llvm code using the LLVM api: %myString = alloca [13 x i8], i32 13 store [13 x i8] c"Hello world.\00", [13 x i8]* %myString %tmp1 = getelementptr [13 x i8]* %myString, i32 0, i32 0 %tmp2 = call i32 (i8*, ...)* @printf( i8* %tmp1 ) nounwind A simple Hello

TL;DR: I am proposing to add the GCC C Torture suite [1], as an additional external source of tests for the “nightly” test suite. If you are willing to review the patch, it is here: https://reviews.llvm.org/D66887 Background: While working on the RISC-V backend, we have found it useful to use additional test suites beyond the in-tree Clang and LLVM tests and the LLVM nightly tests, in order to

I built llvm + clang from source, a github clone from today: clang version 11.0.0 (https://github.com/llvm/llvm-project.git 91aa67bf290bc7f877b1b90128284863bc31aa43) I compiled a small program: #include <stdint.h> int main() { uint8_t a = 2; uint8_t b = 5; uint8_t c = a * b; } $ clang -c -target riscv32 -march=rv32imc -g main.c Works fine. The dumped assembly seems to not know

Yes - this has been in InstCombine for a long time: https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/InstCombine/InstCombineMulDivRem.cpp#L268 We could say that the canonicalization should be reversed, but that probably uncovers more missing optimizations. The code size concern is legitimate. For example on x86, gcc asm is 2 bytes smaller on this example:

On Fri, 30 Aug 2019 at 17:34, Finkel, Hal J. via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On 8/30/19 10:18 AM, Sam Elliott via llvm-dev wrote: > > TL;DR: I am proposing to add the GCC C Torture suite [1], as an additional external source of tests for the “nightly” test suite. If you are willing to review the patch, it is here: https://reviews.llvm.org/D66887 >

Something that would be good to get clarity on: The RISC-V backend recently had a bugfix patch that got backported to the 10.0.1 branch. The original patch introduced a new virtual method in TargetLowering.h, and the backported patch [1] was rewritten to avoid changing the ABI of libLLVM.so. This feels like some kind of policy decision about the C++ ABI beyond "it's entirely

Op di 3 sep. 2019 om 18:36 schreef Finkel, Hal J. via llvm-dev < llvm-dev at lists.llvm.org>: > On 9/3/19 7:19 AM, Sam Elliott wrote: > > There are 1500 tests total, and about 100 on the platform-agnostic > blacklist. Alex and I do not think this is an onerous burden for > maintenance, either as an external test suite or if the test suite is > imported. > > > >

On 18 August 2016 at 00:08, Renato Golin <renato.golin at linaro.org> wrote: > On 17 August 2016 at 10:14, Alex Bradbury via llvm-dev >> * Codegen >> * Compressed instruction set support (RVC) >> * Benchmarking and comparison to GCC RISC-V (and potentially other archs) > > What about buildbots? > > I'm assuming "check-all" would be enough for