similar to: About CodeGen quality

Hi Mats, It's private backend. I will try describing what I am dealing with. struct S { unsigned int a : 8; unsigned int b : 8; unsigned int c : 8; unsigned int d : 8; unsigned int e; } We want to read S->b for example. The size of struct S is 64 bits, and seems LLVM treats it as i64. Below is the IR corresponding to S->b, IIRC. %0 = load

On 6/15/2017 11:13 PM, Ehsan Amiri wrote: > > Forgot to reply to all > > Hi Eli > >> We want to read S->b for example. The size of struct S is 64 >> bits, and seems LLVM treats it as i64. >> Below is the IR corresponding to S->b, IIRC. >> >> %0 = load i64, *i64 ptr, align 4; >> %1 = %0 lshr 8;

Hi All, If the target supports quad-register R0:R1:R2:R3 (Rn is 32-bit register), is it possible mapping quad-register to v4i32 so that the following example work? typedef int v4si __attribute__ ((vector_size (16))); void foo(v4si i) { v4si j = i; } I don't know how to write CallingConv.td to represent the concept of occupying quad-register R0:R1:R2:R3 once seeing

On 6 Dec 2012, at 07:46, 陳韋任 (Wei-Ren Chen) wrote: > The code below in lib/Target/ARM/ARMRegisterInfo.td is where you > should look into, > > // Integer registers > def R0 : ARMReg< 0, "r0">, DwarfRegNum<[0]>; > def R1 : ARMReg< 1, "r1">, DwarfRegNum<[1]>; > > ... That's the easy part. ARM (AArch32) has 16 registers

> On Jun 16, 2017, at 2:43 PM, 陳韋任 via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > 2017-06-17 4:36 GMT+08:00 upcfrost <upcfrost at gmail.com <mailto:upcfrost at gmail.com>>: > Hi, > > Same here, my backend only has 64bit load/store. But i still use 64bit virt regs and expand/declare missing instructions by myself. > > I'll try

Hi, I've looked through both AMDGPU and Sparc backends, and it seems they also do not perform the thing I want to make. The only backend which is doing it is AArch64, but it doesn't have reg constraints. So, just with an example. I have the following C code: void test() { int a = 1; int b = 2; int c = 3; int d = 4; a++; b++; c++; d++; } Without any frontend optimization is compiles

On Thu, Dec 06, 2012 at 09:13:53AM +0000, David Chisnall wrote: > On 6 Dec 2012, at 07:46, 陳韋任 (Wei-Ren Chen) wrote: > > > The code below in lib/Target/ARM/ARMRegisterInfo.td is where you > > should look into, > > > > // Integer registers > > def R0 : ARMReg< 0, "r0">, DwarfRegNum<[0]>; > > def R1 : ARMReg< 1,

Hi, I'm trying to write an LLVM backend for Epiphany arch, and I wonder if someone can give me some advice on how to implement load/store optimization. The CPU itself is 32-bit, but it supports wider 64-bit loads and store. So the basic idea is to make use of those by combining narrow ones. I've checked how it is done in AArch64 and Hexagon, and my current code is very close to the

Well, that is now a slightly different question. Once the compiler can do 64-bit loads/stores for a 64-bit integer type (e.g. C long long), then an optimization pass should be merging the loads/stores before register allocation, so that appropriate registers can be chosen. On Wed, Jun 28, 2017 at 5:43 AM, Peter Bel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > >

Hi All, When seeing the title "Prolog/Epilog Code Insertion", I'd expect something about XXXFrameLowering.cpp (particular about emitPrologue/emitEpilogue). But the document [1] is about unwind. Is it placed at the right place/section? Thanks. [1] http://llvm.org/docs/CodeGenerator.html#prolog-epilog-code-insertion Regards, chenwj -- Wei-Ren Chen (陳韋任) Homepage:

Hi, I want to increase the number of integer registers in the ARM machine. I don't have any idea how/where I can start. Can anybody help me? By the way, what are the following line in the ARMRegisterInfo.td specify: def qsub_0 def qsub_1 .... Thanks Best Regards, A. Yazdanbakhsh

Also you might need to check use PostRASchedulerList or PostMachineScheduler, PostRASchedulerList is considered deprecated as mentioned in [1]. [1] http://lists.llvm.org/pipermail/llvm-dev/2017-April/112348.html HTH, chenwj 2017-06-10 4:03 GMT+08:00 陳韋任 <chenwj.cs97g at g2.nctu.edu.tw>: > Not saying I am totally understand how thing works, but I think you're > misleading >

Hi, Same here, my backend only has 64bit load/store. But i still use 64bit virt regs and expand/declare missing instructions by myself.  I'll try looking into sparc backend, thanks. Also, only after writing this post I found a bunch of built-in transforms. Still trying to understand how to use those. By the way, constraint-wise (alignment), is there any difference between virt regclass and

Hi Justin, I believe the PTX section in the link below need some love, updating "lib/Target/PTX" to "lib/Target/NVPTX" for example. Would you like to take a look? http://llvm.org/docs/CodeGenerator.html#the-ptx-backend Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667

Hi 陳韋任, Sorry for the late response. On Apr 21, 2012, at 8:03 PM, 陳韋任 wrote: > I have a native compile and the result seems better... You can compare > the result of cross compile [1] and the native compile [2]. > > Any though? > I'm not particularly happy about the failures here. We need to get to the bottom of them. In the previous email, you tried setting CFLAGS and

Hi all, I think it's Gentoo's bug, but I want to know if anyone has the same issue here. I am compiling LLVM trunk on Gentoo (gcc 4.5.2), and I get error message below, --- make[4]: Entering directory `/nfs_home/chenwj/llvm-3.1/svn/build/tools/clang/lib/Frontend' llvm[4]: Compiling InitHeaderSearch.cpp for Release+Asserts build

Hi weiren, Thanks for your suggestion! Yes, I am trying to do this "nested flattening". It seems that I need a post-dominator tree-based algorithm to flatten the nested loops from the innermost to the outermost, level by level. Is there any feature already existed in LLVM tools? Or similar? On Sun, Oct 22, 2017 at 2:31 AM, 陳韋任 <chenwj.cs97g at g2.nctu.edu.tw> wrote: > If

Sounds like you break a single getelementptr into a few smaller ones, then do CSE-like optimization? 2017-06-14 21:11 GMT+08:00 Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org>: > On 6/14/2017 7:44 AM, 陳韋任 via llvm-dev wrote: > >> >> Skim through Hexagon backend, I notice there is HexagonCommonGEP.cpp >> which seems >> try to do something on

Thanks for the info, Philip. I will update the LLVM Programmer’s Manual first. Regards, chenwj Wei-Ren Chen (陳韋任) Homepage: https://people.cs.nctu.edu.tw/~chenwj 2017-04-02 18:11 GMT+08:00 Philip Pfaffe <philip.pfaffe at gmail.com>: > Hi chenwj, > > http://llvm.org/doxygen/Statistic_8h_source.html is the correct one. The > other two are remnants from older doxygen deployments.

Hi All, I have two trivial patches waiting for review. - https://reviews.llvm.org/D33281 - https://reviews.llvm.org/D32929 Anyone? :-) Regards, chenwj -- Wei-Ren Chen (陳韋任) Homepage: https://people.cs.nctu.edu.tw/~chenwj -------------- next part -------------- An HTML attachment was scrubbed... URL: