On Tue, Mar 12, 2013 at 9:19 AM, Renato Golin <renato.golin at linaro.org>wrote:> On 12 March 2013 15:28, Hal Finkel <hfinkel at anl.gov> wrote: > >> Can't we just paste in a RNG so that we'll get the same output on all >> systems (and can still use the reference output)? >> > > We can, though other tests suffer from the same issue. Would be good to > have a solution to all of them without pasting the same code on all of them. > > I really thought that the native output was always generated by the > "native compiler" which is normally GCC. Removing the reference output > doesn't work, since it just creates an empty file instead. The Makefile is > too simple to mean anything, but maybe there's some environment variable > that needs setting to make LNT get the result from a GCC run... >The test suite supports multiple modes, one mode in which the native output is generated by an executable built by the native compiler, another in which the output is compared to a reference compiler. The former mode is historically what the test suite did, the latter mode is substantially faster (and independent of bugs in the native CC). - Daniel> --renato > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130312/f96a0bfc/attachment.html>
On 12 March 2013 16:48, Daniel Dunbar <daniel at zuster.org> wrote:> The former mode is historically what the test suite did, the latter mode > is substantially faster (and independent of bugs in the native CC). >Yes, I agree this is better for many cases, but not for all. Implementing RNG that is good enough for the tests' purposes, fast enough not to steal the benchmarks' hot spots and does not use target/library-specific code is not trivial. I think that, in this particular case, having bugs in GCC is far less problematic than assuming fixed outputs. I've tried USE_REFERENCE_OUTPUT := 0 on the Makefile, but the test.log still prints it as 1 (and fails). cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130312/5852fa34/attachment.html>
On Tue, Mar 12, 2013 at 10:23 AM, Renato Golin <renato.golin at linaro.org>wrote:> On 12 March 2013 16:48, Daniel Dunbar <daniel at zuster.org> wrote: > >> The former mode is historically what the test suite did, the latter mode >> is substantially faster (and independent of bugs in the native CC). >> > > Yes, I agree this is better for many cases, but not for all. Implementing > RNG that is good enough for the tests' purposes, fast enough not to steal > the benchmarks' hot spots and does not use target/library-specific code is > not trivial. >This is not true, all one needs to do is replace existing srand(), rand() with some specific platforms version (and those are usually very simple RNGs). If the code is already using srand()/rand() then there is no reason to assume somehow the benchmark is worse if it always used the FreeBSD one, say, as opposed to a platform specific one. - Daniel I think that, in this particular case, having bugs in GCC is far less> problematic than assuming fixed outputs. > > I've tried USE_REFERENCE_OUTPUT := 0 on the Makefile, but the test.log > still prints it as 1 (and fails). > > cheers, > --renato >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130312/4bcc2d5e/attachment.html>
Hi,
We are new in LLVM...
We want to execute JIT'ed code that links to functions inside our
application
For example, the JIT has compiled code like
extern void open_device(Device * dev);
int foo_bar() { Device dev; ... ; open_device(&dev); ...;}
/
/where open_device() is a function in our own code, that
has initialized and called the ExecutionEngine.
Of course when running we get the error message
LLVM ERROR: Program used external function open_device which could not
be resolved!
How can we dynamically resolve such external addresses ?
We have seen in the documentation llvm is trying to link
unresolved symbols with dlsym(). In this case it fails.
Is there a hook we can plug in the execution engine so that we control
ourselves
the resolution of external symbols after dlsym() has failed.
We still want to try dlsym() first and only when it fails then take
control.
We do not see this in the execution engine interface.
Of course we want to do the resolution only once upon the first call
not for each call to foo_bar() like a profiling listener would do.
Comments will be appreciated...
Vania
--
-- Vania Joloboff
Hi Vania,
If I understood correctly, you have an executable, which is JITing code
that has dependencies on the symbols of entire executable. In case dlsym
cannot find this symbol, try to link your executable with -rdynamic (gcc)
or --export-dynamic (ld):
-rdynamic
Pass the flag -export-dynamic to the ELF linker, on targets that
support it. This instructs the linker to add all symbols, not
only
used ones, to the dynamic symbol table. This option is needed for
some uses of "dlopen" or to allow obtaining backtraces from
within
a program.
- D.
2013/3/13 Vania Joloboff <vania.joloboff at inria.fr>
> Hi,
>
> We are new in LLVM...
> We want to execute JIT'ed code that links to functions inside our
> application
> For example, the JIT has compiled code like
>
> extern void open_device(Device * dev);
> int foo_bar() { Device dev; ... ; open_device(&dev); ...;}
> /
> /where open_device() is a function in our own code, that
> has initialized and called the ExecutionEngine.
> Of course when running we get the error message
>
> LLVM ERROR: Program used external function open_device which could not be
> resolved!
>
> How can we dynamically resolve such external addresses ?
> We have seen in the documentation llvm is trying to link
> unresolved symbols with dlsym(). In this case it fails.
> Is there a hook we can plug in the execution engine so that we control
> ourselves
> the resolution of external symbols after dlsym() has failed.
> We still want to try dlsym() first and only when it fails then take
> control.
>
> We do not see this in the execution engine interface.
> Of course we want to do the resolution only once upon the first call
> not for each call to foo_bar() like a profiling listener would do.
>
> Comments will be appreciated...
> Vania
>
>
>
>
>
>
>
>
> --
> -- Vania Joloboff
>
> ______________________________**_________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>
http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130313/ba8313f5/attachment.html>