Outdated information in CFEBuildInstrs.html

http://llvm.cs.uiuc.edu/docs/CFEBuildInstrs.html have lines:

Add the directory containing the tools to your PATH.
 % set path = ( `cd llvm/tools/Debug && pwd` $path )

In my LLVM object directory at LLVM build (obj != src)
obj/tools/Debug don't exist (instead exist obj/Debug)

Also i recheck obj == src case with same result.

I am use and I think command must be updated to
 set path = ( `cd llvm/Debug/bin && pwd` $path )

Vladimir

Re: Outdated information in CFEBuildInstrs.html

John T. Criswell wrote:

> Vladimir Merzliakov wrote:
>
>> http://llvm.cs.uiuc.edu/docs/CFEBuildInstrs.html have lines:
>>
>> Add the directory containing the tools to your PATH.
>> % set path = ( `cd llvm/tools/Debug && pwd` $path )
>>
>> In my LLVM object directory at LLVM build (obj != src)
>> obj/tools/Debug don't exist (instead exist obj/Debug)
>>
>> Also i recheck obj == src case with same result.
>>
>> I am use and I think command must be updated to
>> set path = ( `cd llvm/Debug/bin && pwd` $path )
>
>
> Right.  The location of these files changed a few weeks ago.
>
> I've fixed the Getting Started Guide.

Er, I meant CFE Build Instructions.

Sorry.  I haven't had my first coke of the morning yet.

-- John T.

>
> Thanks for letting us know!

Re: Outdated information in CFEBuildInstrs.html

Vladimir Merzliakov wrote:

> http://llvm.cs.uiuc.edu/docs/CFEBuildInstrs.html have lines:
>
> Add the directory containing the tools to your PATH.
> % set path = ( `cd llvm/tools/Debug && pwd` $path )
>
> In my LLVM object directory at LLVM build (obj != src)
> obj/tools/Debug don't exist (instead exist obj/Debug)
>
> Also i recheck obj == src case with same result.
>
> I am use and I think command must be updated to
> set path = ( `cd llvm/Debug/bin && pwd` $path )

Right.  The location of these files changed a few weeks ago.

I've fixed the Getting Started Guide.

Thanks for letting us know!

-- John T.

>
> Vladimir
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev <at> cs.uiuc.edu         http://llvm.cs.uiuc.edu

GetElementPtr for packed types and VS build

As I was working with packed types it became apparent that I sometimes 
need to access individual elements - I fixed this by implementing GEP 
for packed types with just 2 small patches.

When I updated from the CVS today after about 2 weeks, I got a lot of 
problems with the VS build. I will send the updated project files 
directly to Reid so he can check them in as they are rather large. There 
is also one more issue which prevents the CVS version from compiling - 
in lib/ExecutionEngine/JIT/JITEmitter.cpp line 266 there is:

if (GlobalVariable *GV = dyn_cast<GlobalVariable>(V)) {
     GlobalVariable *GV = cast<GlobalVariable>(V);
     .
     .

This is obviously nonsense and is an error with the VS compiler since GV 
is being defined twice in the same scope using it's non-standard scoping 
rules. Just delete the line with the cast and it's fine...

m.

Index: lib/Target/TargetData.cpp
===================================================================
RCS file: /var/cvs/llvm/llvm/lib/Target/TargetData.cpp,v
retrieving revision 1.53
diff -u -r1.53 TargetData.cpp
--- lib/Target/TargetData.cpp	2 Nov 2004 22:18:18 -0000	1.53
+++ lib/Target/TargetData.cpp	26 Nov 2004 09:46:45 -0000

Could LLVM help me?

Howdy:
    I'm a newbie of LLVM. I want to make sure that my way is correct.
Plz tell me...
we design a new processor with a new arch. we wanna get a compiler as
fast as possible. The target code of the new compiler  is machine
code.
 So, is it I just to create a whole new backend for our new processor,
right? And then????

Thx.

Re: Could LLVM help me?

>     I'm a newbie of LLVM. I want to make sure that my way is correct.
> Plz tell me...
> we design a new processor with a new arch. we wanna get a compiler as
> fast as possible. The target code of the new compiler  is machine
> code.
>  So, is it I just to create a whole new backend for our new processor,
> right? And then????

Yes. LLVM would be great for your project. Please check out the document
on how to write a backend.
http://llvm.cs.uiuc.edu/docs/WritingAnLLVMBackend.html

-Tanya

Re: GetElementPtr for packed types and VS build

On Wed, 1 Dec 2004, Morten Ofstad wrote:

> As I was working with packed types it became apparent that I sometimes
> need to access individual elements - I fixed this by implementing GEP
> for packed types with just 2 small patches.

Yup, makes sense.

> When I updated from the CVS today after about 2 weeks, I got a lot of
> problems with the VS build. I will send the updated project files

Ok

> directly to Reid so he can check them in as they are rather large. There
> is also one more issue which prevents the CVS version from compiling -
> in lib/ExecutionEngine/JIT/JITEmitter.cpp line 266 there is:
>
> if (GlobalVariable *GV = dyn_cast<GlobalVariable>(V)) {
>      GlobalVariable *GV = cast<GlobalVariable>(V);

Fixed.

I've applied both of your patches:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041129/021529.html
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041129/021531.html

However, I don't think the second one is correct.  In particular, packed
types often have greater alignment requirements than the underlying type.
With SSE-enabled X86, for example, float requires 32-bit alignment and <4
x float> requires 128-bit alignment.  Your patch is clearly better than

PR466 & library names

If you've recently updated and noticed that the linkers are producing:
"Cannot find library -lc", you need to rebuild your runtime libraries
(cd runtime ; make clean ; make install). Fixing PR466 caused the names
of the libraries built/installed and sought by the linker to change. We
previously installed libXYZ.bc because it was a bytecode file. We now
install libXYZ.a which is an archive library with bytecode file
contents. Subtle difference, but it allows "gccld -lc -lc" and the
dependent libraries feature to work.

Reid.

_______________________________________________
LLVM Developers mailing list
LLVMdev <at> cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev

Adding xadd instruction to X86

Hi,

I'm trying to add the xadd instruction to the X86 back end. 
xadd r/m32, r32 
exchanges r/m32 and r32, and loads the sum into r/m32.  I'm
interested in the case where the destination operand is a
memory location.

I've added the following entry to X86InstrInfo.td:
def XADD32mr  : I<0x87, MRMDestMem,
                (ops i32mem:$src1, R32:$src2),
                "xadd{l} {$src1|$src2}, {$src2|$src1}">;

The xadd is emitted for the intrinsic function:
call int (<integer type>*, <integer type>)*
%llvm.atomic_fetch_add_store(<integer type>* <pointer>,      

<integer type> <value>)

I currently have the following code (PtrReg contains the
pointer argument, ValReg the value arg, and TmpReg an unused
register.):

addDirectMem(BuildMI(BB, X86::XADD32mr, 4,
TmpReg).addReg(TwoReg), ValReg);

This fails the assertion isMem.  Any help with this would be
appreciated.

Thanks,

VC++ patches

I tried to build the latest using Visual Studio and ran into a few
problems.  Patches attached to fix most of them.  However, there's one I
can't easily fix.

DynamicLibrary.cpp is messed up.  lib/System/DynamicLibrary.cpp does NOT
include platform/DynamicLibrary.cpp like it's supposed to, so the
Windows-specific implementation is not compiled.  What's there now is
very Unix-centric and gives me lots of link errors.  All the
Unix-platform-specific implementations are ignored also, but obviously
that doesn't cause any problems.  Furthermore, the implementations of
the platform-specific files do not mesh well with the "common" file.

Also, the patch I submitted to fix Configure.vcproj weeks ago was never
committed.  This new patch includes that fix.

_______________________________________________
LLVM Developers mailing list
LLVMdev <at> cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev