search for: r26

...ta + .import __libc_init, code + + .global _start + .export _start, ENTRY + .type _start, at function + + .proc + .callinfo + +_start: +/* extend the stack by 64-bytes */ + ldo 64(%sp), %sp + +/* %r25 = argc + * %r24 = argv + * envp = argv + (argc + 1) + * elfdata = (argv - 4) + */ + ldo -4(%r24), %r26 + +/* load global data */ + ldil L%$global$, %dp + ldo R%$global$(%dp), %dp + +/* parisc abi puts the atexit pointer in %r23, see ELF_PLAT_INIT() */ + copy %r23, %r25 + +/* branch to __libc_init */ + bl __libc_init,%r2 + nop +/* break miserably if we ever return */ + iitlbp %r0,(%sr0,%r0) /* illega...

...M and our backend, become more and more complex we have the following problem with our backend: In most cases registers are spilled on function entry to stack slots and reloaded on function exit. At some points registers are spilled and reloaded via register scavenging. There is just one register (r26) to which a register is written and read from. I had the impression that such a register as an emergency spill slot is enough. But in combination with function calls this fails quite often: registers are not spilled to stack slots but ALL registers are written to the emergency spill slot (register...

Author: ultrotter Date: 2006-02-19 18:38:10 +0000 (Sun, 19 Feb 2006) New Revision: 26 Added: trunk/debian/patches/30xenchangeset.dpatch Modified: trunk/debian/patches/00list trunk/debian/patches/10sysconfig.dpatch trunk/debian/rules Log: Add 10sysconfig.dpatch description Add 30xenchangeset.dpatch to make the xen changeset configurable Force the xen changeset to be the correct one

Hi. The patch I send before was too large so that it was dropped from the maling list. I'm sending again with smaller size. This patch set is the xen paravirtualization of hand written assenbly code. And I expect that much clean up is necessary before merge. We really need the feed back before starting actual clean up as Eddie already said before. Eddie discussed how to clean up and suggested

Hi. The patch I send before was too large so that it was dropped from the maling list. I'm sending again with smaller size. This patch set is the xen paravirtualization of hand written assenbly code. And I expect that much clean up is necessary before merge. We really need the feed back before starting actual clean up as Eddie already said before. Eddie discussed how to clean up and suggested

Hi. I rewrote the patch according to the comments. I adopted generating in-place code because it looks the quickest way. The point Eddie wanted to discuss is how to generate code and its ABI. i.e. in-place generating v.s. direct jump v.s. indirect function call Indirect function call doesn't make sense because ivt.S is compiled multi times. And it is up to pv instances to choose in-place

Hi. I rewrote the patch according to the comments. I adopted generating in-place code because it looks the quickest way. The point Eddie wanted to discuss is how to generate code and its ABI. i.e. in-place generating v.s. direct jump v.s. indirect function call Indirect function call doesn't make sense because ivt.S is compiled multi times. And it is up to pv instances to choose in-place

..., however, just 100 or so lines (attached as test.s.part). >From the trace I posted yesterday (also attached), at the top: lines 2646-2648 print "632: iload" lines 2649-2652 print "local_5_114 = 57" (the correct value) >From line 2651 you can see that the 57 came from r26. At the bottom: lines 4901-4903 print "632: iload" lines 4904-4907 print "local_5_420 = 261095424" (the junk value) >From line 4906 you can see that the 261095424 also came from r26. Looking at what happens to r26 in the meantime it seems it's being used to hold temp...

On 2008-06-11, at 13:16, Gary Benson wrote: > Duncan Sands wrote: > >> Can you please attach IR which can be compiled to an executable >> (and shows the problem). > > I've been generating functions using a builder and then compiling > them with ExecutionEngine::getPointerToFunction(). Is there some way > I can get compilable IR from that?

Duncan Sands wrote: > Can you please attach IR which can be compiled > to an executable (and shows the problem). I've been generating functions using a builder and then compiling them with ExecutionEngine::getPointerToFunction(). Is there some way I can get compilable IR from that? Cheers, Gary -- http://gbenson.net/

...warfRegNum<[21]>; def R22 : DLXR<22, "r22">, DwarfRegNum<[22]>; def R23 : DLXR<23, "r23">, DwarfRegNum<[23]>; def R24 : DLXR<24, "r24">, DwarfRegNum<[24]>; def R25 : DLXR<25, "r25">, DwarfRegNum<[25]>; def R26 : DLXR<26, "r26">, DwarfRegNum<[26]>; def R27 : DLXR<27, "r27">, DwarfRegNum<[27]>; def R28 : DLXR<28, "r28">, DwarfRegNum<[28]>; def R29 : DLXR<29, "r29">, DwarfRegNum<[29]>; def R30 : DLXR<30, "r30&quo...

...r9: 0x00000000 r10: 0xbffff78b r11: 0x00000026 r12: 0x8fe71ac7 r13: 0x00000000 r14: 0x000021bc r15: 0x00000000 r16: 0xbffffcb4 r17: 0x00000001 r18: 0x00000000 r19: 0x000016d4 r20: 0x00000000 r21: 0x00000000 r22: 0x00000000 r23: 0x00000000 r24: 0x8fe4b3d8 r25: 0x00000002 r26: 0x00000002 r27: 0x00000000 r28: 0x00001610 r29: 0x00000000 r30: 0x8fe484d8 r31: 0x8fe09ecc

I'm running dovecot on an OpenBSD 3.7 server and after upgrading to RC25, the daemon started exiting with: Fatal: Time just moved backwards (1173221579 -> 1173221578)! This might cause a lot of problems, so I'll just kill myself now. After upgrading to RC26, I've gotten the error: Error: Time just moved backwards by 1 seconds. I'll sleep now until we're back in

Hello, I run the domain for the school here with qmail and vpopmail on FreeBSD with dovecot from the ports. I'm running dovecot 1.0.r26 and everything is working great. I been noticing that dovecot isn't updating when the user last logged in.. and I can't seem to figure out why. I also can't seem to find anything in the archives about it.. so am I the only one? name: bcook passwd: $1$ clear passwd: comment/gecos:...

...homedir = /home/%U/%U winbind separator = + [printers] comment = All Printers path = /tmp create mask = 0700 printable = Yes browseable = No [x062nc4] path = /home/%u browseable = No [homes] comment = Linux/Samba on IBM 9672-R26 Personal Shares path = %H username = %S read only = No create mask = 0700 directory mask = 0700 inherit permissions = Yes browseable = No exec = preexec = csh -c 'echo [g062] comment = Common Directory for 062 path...

hi... i try to make dovecot (v1.0.r26) in solaris 10 and i have the following problem # ./configure --with-ldap ... ... Install prefix ...................... : /usr/local File offsets ........................ : 64bit I/O loop method ..................... : poll File change notification method ..... : none Building with SSL support ......

...have that code in my backend, but unless I do the following, the registers are never considered 'live' into the call. / Handle a function call let isCall = 1, Defs = [ R0, R1, R2, R3, R4, R5, R6, R7, R8, R9, R10, R11, R12, R13, R14, R15, R16, R17, R18, R19, R20, R21, R22, R23, R24, R25, R26, R27, R28, R29, R30, R31, R32, R33, R34, R35, R36, R37, R38, R39, R40, R41, R42, R43, R44, R45, R46, R47, R48, R49, R50, R51, R52, R53, R54, R55, R56, R57, R58, R59, R60, R61, R62, R63, R64, R65, R66, R67, R68, R69, R70, R71, R72, R73, R74, R75, R76, R77, R78, R79, R80, R81, R82, R83, R84, R85,...

...9;XXX' ?) def TempRegs : RegisterClass<"MFLEXG", [XXX], 32, [R0, R1, R2, R3, R4, R5, R6, R7, R8, R9, R10, R11, R12, R13, R14, R15, R16, R17, R18, R19, R20, R21, R22, R23, R24, R25, R26, R27, R28, R29, R30, R31]> { } 3) If not, does this means I have to write the whole LLVM backend based on the basic llvm::TargetMachine & llvm::TargetData, just like what CBackend does? ----------------------------------------------------...

Hi Micah, > In X86InstrInfo.td for Call Instructions, it mentions that Uses for > argument registers are added manually. Can someone point me to the > location where they are added as the comment doesn't reference a > where or how? the register uses are added by the function X86TargetLowering::LowerCall() during the DAG Lowering phase. This is the relevant code segment: // Add

I have updated the klibc patchset based on feedback received. In particular, the patchset has been reorganized so as not to break git-bisect. Additionally, this updates the patch base to 2.6.17-git12 (d38b69689c349f35502b92e20dafb30c62d49d63) and klibc 1.4.8; the main difference on the klibc side is removal of obsolete code. This is also available as a git tree at: