similar to: RFC: Harvard architectures and default address spaces

Hello Hal, > Add this information to DataLayout and to use that information in relevant places. This sounds like a much better/cleaner idea, thanks! On Wed, Jul 12, 2017 at 1:13 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 07/11/2017 12:54 AM, Dylan McKay via llvm-dev wrote: > > Hello all, I’m looking into solving an AVR-specific issue and would love > to hear

I’m not sure if it’s truly deterministic. It always gives the same results (so far) on my machine but I’m not sure that’s enough. My guess is it’s probably going to be deterministic on one machine but might well not be deterministic across environments. Like it might give varying results if cross compiled on different hosts, macOS vs intel Linux vs arm vs s390. (Obviously AVR is always a cross

We have a test that looks like this… define void @array16_store() { ; CHECK-LABEL: array16_store: ; CHECK: ldi [[REG1:r[0-9]+]], 204 ; CHECK: ldi [[REG2:r[0-9]+]], 170 ; CHECK: sts int.array+3, [[REG2]] ; CHECK: sts int.array+2, [[REG1]] ; CHECK: ldi [[REG1:r[0-9]+]], 187 ; CHECK: ldi [[REG2:r[0-9]+]], 170 ; CHECK: sts int.array+1, [[REG2]] ; CHECK: sts int.array, [[REG1]] ; CHECK: ldi

Hello, I am working on a AVR backend and have a version up and running that will convert LLVM IR code to assembly code for my target. I have written a bunch of instructions from the AVR Instruction Set in AVRInstrInfo.td and not much else. In a simple test case I am attempting to compile (if that is the word you are supposed to use for this operation) test.ll: define i8 @foo(i8 %a, i8 %b) {

Hi, Compiling for both x86 and ARM with llc aborts after this pass. I have a simple helloworld.c program. I am attaching the .ll file created by: *clang -O3 -g -emit-llvm hello.c -c -o hello.bc* *llvm-dis hello.bc* Thanks again for the response! Shruti On Mon, May 19, 2014 at 1:28 AM, Tobias Grosser <tobias at grosser.es> wrote: > On 19/05/2014 00:54, shruti padmanabha wrote: >

Exactly the same... ??? [root at plexvm ~]# mount -t cifs //192.168.1.200/mp3 /home/plex/Musique --verbose -o username=plex,password=plex,domain=DERWAEL,ro,auto,vers=3.0 mount.cifs kernel mount options: ip=192.168.1.200,unc=\\192.168.1.200\mp3,vers=3.0,user=plex,domain=DERWAEL,pass=******** mount error(2): No such file or directory Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

As much as I like this idea for it's use in languages with type systems like Haskell and Scheme, this proposal would limit LLVM to non-Harvard architectures. That's generally a really small minority of all processors, but it would mean there could never be a clang-avr. An alternative you could use is, instead of using the function pointer as the variable where you are referring to a

I'm not across most of this debug info stuff but I'll stomp in here to confirm that AVR is a Harvard architecture, with separate addressing for the data and program buses via specialized instructions which will load from either one, or the other, but never both. It makes sense that this particular problem would also affect AVR - the backend does have some issues with debug info

I’ve encountered this kind of architecture before, a long time ago (academically). In a flat-address-space machine such as X64, there is still an instruction/data distinction, but usually only down at the level of I-cache versus D-cache (instruction fetch versus data fetch). A Harvard architecture machine exposes that to the programmer, which effectively doubles the available address space.

On Mon, 2008-05-19 at 20:40 +0300, Pertti Kellomäki wrote: > The only hitch is that in the MCU world people expect to be > able to write interrupt handlers and the like in C... Most of the support that I have seen for this in other compilers amounts to custom calling conventions and preambles. Are you thinking of more than this?

On Mon, Mar 16, 2020 at 9:31 AM Robinson, Paul <paul.robinson at sony.com> wrote: > With AVR being affected, upstreaming a patch to put segment selectors into > .debug_aranges becomes completely reasonable. There would likely want to > be a target hook somewhere to return a value saying what size to use, with > the default implementation returning zero. > *nod* something

I'm a new LLVM developer contributing patches for the AVR platform and I'm trying to understand which parts of the code base are malfunctioning in my case. This LLVM IR... define hidden i32 @setServoAngle3(i32) local_unnamed_addr { entry: %1 = call i32 @myExternalFunction1(i32 %0, i32 119) ret i32 %1 } declare i32 @myExternalFunction1(i32, i32) Is being lowered to this assembly

Hello, On a recent discussion on the cfe-dev mailing list[1] it was asked how easy it was to create a backend to an Harvard Arch chip: different data/function pointer sizes and 16 bit chars (main issues of the targeted arch). Ken Dyck has posted a patch (which solved at least the second problem of 16bit char) on which I have been working on and Douglas Gregor said that different pointer sizes are

Hi Dear All, This is a function which contains Covariance Ratio and Likelihood Distance values (CVRi, LDi). i want to compute the all row's values, that is run this function for nrow(X) times. The X and Y matrices are;

Hello I've been looking at a debuginfo issue on an out-of-tree target which uses DWARF aranges. The problem is that aranges are generated for both data and code objects, and the debugger gets confused when program addresses overlap data addresses. The target is a Harvard Architecture CPU, so the appearance of overlapping address ranges is not in itself a bug as they reside in different

Hi All, While implementing a custom 16 bit target for academical and demonstration purposes, I unexpectedly found that LLVM was not really ready for 8 bit and 16 bit targets. Let me expose why. Target backends can be divided into two major categories, with essentially nothing in between: Type 1: The big 32 or 64 bit targets. Heavily pipelined with expensive branches, running at clock

My experience of having the address space for functions (or function pointers) in the DataLayout i that when the .ll file is parsed we need to parse the DataLayout before any function declarations. That is needed because we want to attribute the functions with correct address space (according to DataLayout) when inserting them in the symbol table. An alternative would be to update address space

> [llvm-commits] PATCH for PIC16 target. Do you have a link? Google isn't turning this up. I'd be interested in hearing more about this experience... Thanks, John

> Do you have a link? Google isn't turning this up. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080512/062319.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL:

I needed to be able to update stub pointers for hot functions that get recompiled in a lazy JIT that uses CompileOnDemandLayer. In order to do this I added a method that allows pointers to be updated but does not expose any of the other internals of the COD layer. Does anyone have a cleaner way to do this? Has something to facilitate this already been added? Would it be possible to merge this