vector data types support in the LLVM interpreter part 2

[Ouriel, Boaz]

Hi Nick, 

The Interpreter has a number of users, inside and outside of Intel.
I think that our presentation at the LLVM Euro last week demonstrates the need for such a tool.  
As you can see we started working with the community on improving the Interpreter.
Please let me know if there are other parts of the infrastructure that needs to be improved.

Thanks,
Boaz

-----Original Message-----
From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Nick Lewycky
Sent: Friday, May 03, 2013 22:10
To: David Tweed
Cc: Veselov, Yuri; llvm-commits at cs.uiuc.edu
Subject: Re: vector data types support in the LLVM interpreter part 2

David Tweed wrote:
> |I'm interested in deleting the llvm intepreter entirely. Are you using
> |it? Why?
>
> Obviously this is just a shot in the dark, but possibly connected with
>
> http://llvm.org/devmtg/2013-04/#talk10
>
> ?

I see.

> In connection with your general question, could you elaborate on the
> motivation
> for wanting to delete the llvm interpreter please? I can imagine it's
> obviously
> some overhead to keep it fitting as llvm internals get refactored, but is it
> sufficient that you think dropping that route is best? (I don't have any
> plans
> to make any particular use of it in the future, but it seems like it might
> be
> useful to have the possibility of using it when bringing up a new platform
> --
> with new platform specific intrinsics which it'd be harder to emulate in
> compiled code.)

It's undermaintained, and has been for a long time. For one example, 
vector types were added in LLVM 1.7, and only now we're looking at 
patches to add support for vectors to the interpreter. Also, it doesn't 
appear to offer any benefits over just using the JIT. It's unnecessarily 
slow, doesn't implement all of the instructions or intrinsics in the IR. 
It does however offer libffi integration, which is nice.

I am deeply concerned about the claim that the llvm interpreter produces 
correct results. Of all the code generators, the interpreter is the most 
likely to be wrong, as it is certainly the least tested.

Nick
_______________________________________________
llvm-commits mailing list
llvm-commits at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.