search for: as0

...d?" > > One obvious drawback to such an approach is that dereferencing char* becomes relatively expensive, though for the sort of code being predominantly run on a DSP that might be acceptable. We're using multiple address spaces to describe two pointer representations for CHERI: AS0 is a 64-bit pointer that's represented as an integer, AS200 is a capability (256-bit fat pointer with base, length, permissions, enforced in hardware). We had to fix a few things where LLVM assumes that pointers are integers, but the different size pointers in different address spaces part wor...

...rogram address >> spaces. We propose an implementation of multiple address spaces in >> D91428 [1] - this is a backwards compatible change. >> >> # Problem >> >> Currently the default program address and the default data address space >> is the same, namely AS0. We can at the moment, change the program >> address space with P<n> in the data layout string. This allows harvard >> architectures to separate code and data into different address spaces. >> However, only one program address space is allowed. >> >> At Igalia [2...

> -----Original Message----- > From: Michele Scandale [mailto:michele.scandale at gmail.com] > Sent: Saturday, August 10, 2013 5:30 AM > To: Micah Villmow > Cc: James Courtier-Dutton; LLVM Developers Mailing List > Subject: Re: [LLVMdev] Address space extension > > > [Micah Villmow] The backends won't understand your address space > > mapping. The backends

...189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 Which is produced by the IR in as0.ll The only difference in the two IR dumps is that the parameters to the kernel are in different address spaces. https://llvm.org/docs/AMDGPUUsage.html#amdgpu-opencl states that address space 1 should be the global address space for amdgiz runtimes like ROCm and AS 0 is the generic (flat) address...

> [Micah Villmow] The backends won't understand your address space mapping. The backends should expose their address spaces that they support, their sizes and their overall semantics. It should be documented just like the calling convention is documented. It is then the job of the frontend to map whatever source language address spaces are used onto the correct address spaces for the

I'm not sure what the usual "ping time" is for llvm-dev, but may I ask if there are any updates on this? It appears that the following lines are the root cause of the reordering (https://github.com/llvm/llvm-project/blob/fdcb27105537f77c78c4473d4f7c47146ddbab69/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp#L2175): // Handle gep(bitcast x) and gep(gep x, 0, 0, 0). Value

> On Apr 30, 2018, at 15:05, John McCall via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> On Apr 30, 2018, at 2:58 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: >> On Mon, Apr 30, 2018 at 11:14 AM, John McCall <rjmccall at apple.com> wrote: >>> The LLVM address space design has pushed well beyond the sensible boundaries >>> of

> On Apr 30, 2018, at 2:58 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > On Mon, Apr 30, 2018 at 11:14 AM, John McCall <rjmccall at apple.com> wrote: >> The LLVM address space design has pushed well beyond the sensible boundaries >> of less-is-more and really needs some concerted effort to actually define the expected >> properties of different

...2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: steve at mailaps.org I have openssl-0.9.6c, zlib-1.1.4 and perl5.004 installed on IRIX 5.3 system (MIPS IP22) with gcc 2.6.3. The only errors I find in config.log are of the following form: as0: Error: conftest.c, line 1:undefined assembler operation: .stabs .stabs "/usr/people/steves/build/openssh-3.1p1/",100,0,0,$Ltext0 but config exits gracefully. issuing 'make' then produces the following output: # make conffile=`echo sshd_config.out | sed 's/.out$...

Hi everyone, Where I work, there are several standards (heh) for position codes for staff and faculty. For instance, a Dean could be listed as DEA or DEN. An Assistant Professor could be AST or ASO. There are some cases where typos have crepts into the system, and AS0 (zero) could have meant ASO. Now, beyond getting those responsible to clean up their data (we are), I need to deal with this now. I was hoping Single Table Inheritence would help me. For all legit codes (you know, the ones IT standardized on), we could have an id, code, and description. Simple...

> It's definitely doable, but I'd be worried about the maintenance burden. Yes, that is a problem. We are currently not allowed to reveal our target (which has 16-bit bytes, and registers with non-power-of-two bit widths) fully, and therefore not able to submit it upstream. One idea we have toyed with is to create a simple "dummy" version of our target, just to be able